Re: Recursive CL - Data decimal error

[Pete Hall <pbhall@xxxxxxxxxx>]

At 10:39 10/23/2001, Fran Dennoncourt wrote:
>Is there a known bug with calling a CL recursively passing decimal data as
>a parameter to the CL?
>I don't seem to have any problems with a character field. But if I pass
>numeric and logical, part of the data seems to get truncated when the
>second pass is run.
>The first pass checks to see if it is an interactive job. If so, it submits
>itself passing the two input parameters from an RPGLE program: numeric
>(*DEC 9/0) and and indicator (*LGL). The error occurs when I use a CHGVAR
>command with the numeric field.
>If I remove the SBMJOB code and let the execution drop through to the
>CHGVAR, no problem.

Not a bug. That's just the way it works. When you use the CALL command,
either from a command line, or from within SBMJOB, variables cannot be
passed by reference (there's nothing to reference, so how can they be?).
Consequently, CALL examines the parameter data. If it finds a number (a
series of numeric digits), it converts that number to a packed 15.5 value,
which is what the submitted program will receive, regardless of the length
or decimal precision of the value that was passed. Same with a logical
value, which will look like a number to the CALL command. You can solve
this conundrum by doing one of two things:

Pass all numeric values as P15.5. That way, the receiving code is expecting
what it gets from the CALL command, regardless of the environment it runs in.

or (preferred, at least by me)
Write your own command, which knows the correct data types of the
parameters and passes them accordingly. It's really very easy to write
simple commands.


Pete Hall
pbhall@execpc.com
http://www.execpc.com/~pbhall/