RE: CL Parameter ends up fulla crud.

Larry,

This seems the correct behavior to me.....  Remember that all parms are
passed by reference, and since you declared the parm to be eight bytes, in
your program you see eight bytes.  Now, in this case, you passed a one byte
parm (by reference).  The garbage you're seeing is data that the compiler
parked immediately following the one byte variable in your calling program.
This might be another variable, or it might be some internal buffer,
whatever.....  

One possible solution might be to define (in the calling program) the one
byte parm as a subfield in a datastructure, and ensure that the next seven
bytes are x'40' (blanks).  But this would be a lot of work since this would
need to be done in every program that tries to pass short parms....

There are "operational descriptors" that can be used sometimes to describe
parameter sizing, but I don't think this works in CL....  (Not very familiar
with OpDesc)...

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Larry Bolhuis
Sent: Monday, January 16, 2006 3:41 PM
To: Midrange Systems Technical Discussion
Subject: CL Parameter ends up fulla crud.


Two CLLE PGMs.

Called PGM has three parms 10, 8 and 8 bytes all character.

Calling pgm passes in 10, 8 and 1 byte parms, also all character.

Everything comes across but parm 3 has 7 bytes of crud after byte 1, 
which is correct.

This ain't supposed ta happen, correct?  We'd fix the one byte parm to 8 
bytes but there are hundreds of these in the system and the crud just 
appears randomly.

i5, V5R3, late 2005 CUMes and Groups.

 Thoughts?

     - Larry.