RE: Problems with parameter passing

This does not seem exactly right somehow. I believe the issue is about the
length of the parameter as defined in the called program. The rule for
character literals being passed as parameters is, the system will pad out to 32
characters with blanks. So you are guaranteed blanks only out to 32 characters.
If the receiver parameter is less than or equal to 32 long, you are in great
shape - no problem. As soon as that variable is longer than 32, you get what
Pat shot at - whatever is in memory is passed to the called program or
procedure.

If I remember what Paul Tuohy said at COMMON recently, the called program
assigns storage for its parameters, with the sizes it knows. There is likely
some kind of memory copy to put the parameters into that storage, for as long
as each parameter needs. When you use literals from the command line or in the
CMD parm of SBMJOB, you can see what you get. If you use commands to front your
call, the memory is properly cleared for the size of the parameter in the
command.

This is also why the trick of putting a character after the "last" position
works - that marker is never copied because it is not within the length that is
defined in the called routine.

So there is no estimating of what the parameter should be - that is completely
known to the called routine - and the system always holds to the 32-character
limit as to padding with blanks.

There IS a great KB article at IBM support, as well as the FAQ here at
MIDRANGE-L

HTH
Vern

-------------- Original message --------------
From: "DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>

Is there a difference between the CL processor and the command parser?
This always confuses me.



Yes there is a difference....

In a CLP (program), the compiler can determine the attributes of data being
passed, and will not need to analyze the parameter data in order to declare
storage. There are no ambiguities in compiled CL.

In a command line scenario, you would most likely create a *CMD object to
serve
as the parser. Again, because the CMD object is compiled, and the command
source fully defines the type and dimensions of the data elements, there is
no
need to analyze the data to determine its type and length.

In the CALL command, when processed from the command line, you do not have
access to parameter sizing information, so the parameter data fields need to
be
analyzed and an "appropriate" size for parameter data need to be determined.

Eric


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.