If you are receiving a data decimal error, then the expected parm is numeric. CLP passing parms should always be character (IMHO) whenever possible or set at 15.5 as a numeric, because a numeric parm is expected to be 15.5 in length and decimals.
Infiniumpro@hotmail.com
++++++++++++++++++++++++++
Previous response::
How have you declared the parameters in the programs ?
E.g.
<pre> PGM PARM(&DEP &OUTQPA)
DCL VAR(&DEP) TYPE(*CHAR) LEN(2)
DCL VAR(&OUTQPA) TYPE(*CHAR) LEN(10)</pre>
————————————————-
This should give you an idea. Last weeks discussion on this general topic.
Why do I have such a problem with passing to a program a 8 byte field using a parm.
Phil
————————————————–
<i>But it takes value as F1F44040404040.</i>
Because that is the value that you supplied, it is the value that you should expect. Commands should not be entered when they are not understood. CALL is a command.
The [help] text associated with CALL explains in some detail what you are seeing. (If you don’t know how to use [help], then the CL Programming manual is also available. The full detail is in the manual as well as in the Info Center for your release.)
Tom
——————————————————————————————————————————————-
CL programs treat decimal variables as packed. I’m not sure what length your incoming numeric parameter is but, based on the value you posted, if you enter the parameter on the command line as <b>x’0000000000014F'</b> you should see the intended value pass into the program.
Splat
Discuss This Question: 5  Replies