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.
This mailing list archive is Copyright 1997-2015 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact