× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



AGlauser wrote:
3. RE: Problems with parameter passing (AGlauser)
Eric DeLong wrote on 11/06/2007 12:22:29:

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.

I understand how that would work if I was passing values by way of a
declared variable in said CLP. But what if you are passing literals? If
I have a CALL command in my CL that is exactly the same as what Glen said
he was typing on the command line, how would the CL compiler know what
attributes the data should have?

Adam:

Although this is the RPG list...

If you are passing literals _and_ you haven't provided any kind of 'prototype' _and_ you are not passing at least as many characters as are expected in the CALLed program (or procedure), then you are at risk of referencing undefined memory in the CALLed program (or proc).

For a CALLed program, you can create a *CMD and that will essentially act like a 'prototype' for use in CL programs. There is no similar 'prototyping' facility for procs in CL, AFAIK.

In ILE CL, I've seen that literals are passed at their exact _quoted_ length regardless of any 32-character boundary. In OPM CL, it seems that literals that are less than 32 characters will at least be padded with blanks out to 32 characters. Reference to anything beyond that generally is "unpredictable". Also, any literals quoted at a length greater than 31 results in memory reserved at the exact quoted length in both ILE & OPM CL. There _might_ be PTFs to "fix" the difference; I quickly stopped counting on it.

The memory that is reserved to hold the literal is at least the length necessary to hold the quoted literal value. But note that if you pass 'ABC ' (seven blanks trailing), then 10 bytes are reserved in ILE CL and 32 bytes are reserved in OPM CL -- the 32 bytes include 29 trailing blanks. That is, literals that are used as parms can cause different results when specified in ILE or OPM CL programs.

I've seen a few converted OPM CLs fall over after being compiled as ILE CL.

If parms are passed from variables, then the variable memory is already reserved. If CALLing and CALLed lengths don't match...?

There is no automated relationship between how you code the parms in the CALLing program and how parms are expected in the CALLed program. Since the CALLed program doesn't even have to exist until the CALL is actually executed, it's not easy for any CALLer to know how to hold literals. This is just as true in a compiled CL program as for the command-line.

Tom Liotta


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.