Why do I have such a problem with passing to a program a 8 byte field using a parm.
Why do I have such a problem with passing to a program a 8 byte field using a parm. Parm field is define as packed(8,0) but as soon as the program tries to acquired the parm I get a Decimal data error.
*ENTRY PLIST PARM NWDATE 8 0
EVAL TodayDate = NWDATE <=== right here it throws out the
Decimal data error.
Software/Hardware used:
AS400
*ENTRY PLIST PARM NWDATE 8 0
EVAL TodayDate = NWDATE <=== right here it throws out the
Decimal data error.
Software/Hardware used:
AS400
ASKED:
October 8, 2009 4:43 PM
UPDATED:
October 10, 2009 6:28 AM
Answer Wiki:
Are you are trying to call this by issuing the command from the command line
Call Myprog 091005
I believe OS/400 will assume that your number is 15-5
Phil
==
If your calling from another program be sure the field is defined as Packed and not Signed in the calling program.
That is exactly what fix my problem. Thanks CharlieBrowne who would of thought the AS400 would use such a random number as 15 5 for the input field size for parm values. And of course alpha's work the way one would expect for passing a parm with a field size that matches the input value field size. Neither of the two books I have had any mention of this in there discussion about parm's. Thanks
==================
One more gotya -- When calling programs from the command lines character fields work well up to 32 characters. That's because OS/400 stores your char entry in a field 32 bytes long or if longer as long as the character string provided. But if your program defines a longer parmater field .. say 512 it will use the string that you pass plus whatever is in memory immediately after that string up to the 512 characters.
Remember when we pass parameters we really pass pointers to the positions in memory.
Phil
All Answer Wiki Contributors:
nitzinger 
385 pts. ,
CharlieBrowne 32,785 pts. ,
philpl1jb 44,070 pts.
385 pts. ,
CharlieBrowne 32,785 pts. ,
philpl1jb 44,070 pts. To see all answers submitted to the Answer Wiki: View Answer History.
The program can be called from the command line by passing the parm as a hex value. Since all numbers are treated as odd in length, you would need to pass something like this as:
Call Program Parm(X’020091009F’)
Notice that the X is outside the quotes. The F is the sign field, present on all packed numbers. It causes the number to be treated as a positive value. I think a D flips the number to negative.
Your 8,0 field will occupy 5 bytes in the program so 10 characters must be passed – nine digits and one sign (F or D)..
Since you’re not passing a PACKED(8,0) parameter value into the program, it’s obvious why the error appears. How would the command line know in what format to store the characters you type? That’s especially since a program may define memory that holds input parms in multiple formats simultaneously. It’s all just redefinition of memory.
Note that your PACKED(8,0) *ENTRY definition doesn’t define the parameter format — rather it defines how your program is going to access the memory, regardless of what’s in it. If you don’t put a valid bit pattern into that memory, then you have to examine how you’re setting up the memory.
The CALL command has very explicit and well defined rules. Numeric literal parameters are stored as PACKED(15,5). Character literal parameters are stored as CHAR(32) when the literal is 32 characters or less in length, and they’re stored as CHAR(N) when they’re N characters in length and (N>32). The same rules apply whether CALL is executed directly on a command line, as the CMD() parameter of SBMJOB or even compiled in a CL program. ( V5R4 description — )
If you need some definition other than what’s documented, you’ll need to do a little work. For numeric values, you can do as already stated — pass the value as hex characters. That will cause the CALL command to store the bytes as characters according to rules for characters. For simple testing, that shouldn’t be a problem; but for long term use, a better method would be to create your own command definition to use in place of CALL.
A command definition provides an IBM-supported method of prototyping your calls for CL programming and command-line use. Parameter definitions will then tell the system how to format your parameter values so that they conform to whatever your program expects.
Tom