RE: *Entry to /Free problem

rpg400-l-request@xxxxxxxxxxxx wrote:

>   3. RE: *Entry to /Free problem (Forbes, Vincent)
>
>None of these suggestions have worked.
>
>I believe that it must have something to do with CL parm passing because this 
>method works fine between RPGLE programs.

Vincent:

That would have been my first guess if I'd seen your message sooner. Not 
because I knew the answer but because of things I've learned from experience.

I'm no CL compiler writer, but I'm pretty sure that a CL DCL statement does 
_not_ allocate anything for a variable unless a VALUE() is also specified. The 
DCL simply holds a variable definition for the compiler to use when it finally 
runs across a statement that needs it.

Speaking about OPM CL and not ILE CL... If you have a CHGVAR that references a 
variable and the CHGVAR is the last statement in a long program, then there is 
no memory allocated for that variable until the CHGVAR is reached in the flow 
of the program.

Even if it's the first DCL, the variable memory is allocated after all other 
variables at a (relatively) higher address. Because of that, it's possible to 
code a series of CHGVARs at the start of your OPM CL and cause variables to be 
positioned in (more or less) contiguous memory. I've used that behavior to pass 
variables larger than 9999 out of OPM CLPs before by putting two or more after 
each other and passing the first.

But it seemed odd that you didn't get an error when you referenced HOLDAY. 
Perhaps it was because DateRange was 80 bytes and that exceeds the 32 byte byte 
command line default. I'm not sure what happens in OPM CL when the first 
reference to a variable is in a CALL command.

(I'd bet Simon Coulter has good info.)

I have seen somewhat different behavior with CALL and variables for ILE CL, but 
have no good way to investigate. With OPM CL, you can at least get something of 
an IRP listing.

Tom Liotta