This is a great thread. Thanks to all who contributed to this thread. I've
certainly gained more knowledge about parameter passing from this. Although
I still get the feeling that there is much to be gained by knowing a little
more in this area.
From what has been said I would (again) infer the following:
1) The responsibility of preparing a parameter for a bound procedure call
lies firmly with the caller. Any required casting/padding/truncating will be
performed by the caller code prior to the call.
2) From the statement above, I would infer that the callee will always
assume that the passed variable is of the exact type/length defined on its
procedure interface. Any code within the called subprocedure will work with
the passed variable as though this is true. Thus incorrect prototyping in
the caller may result in unexpected errors within the called subprocedure.
This may be avoided by specifying opdesc on the PR/PI and calling CEEDOD
within the callee to retrieve the actual parameter details but this is not
fool proof as the caller may not necessarily pass the full descriptor anyway
(due to incorrect prototyping in the caller).
3) The creating and passing of operational descriptors is also the
responsibility of the caller. The called subprocedure may assume at least
the minimal descriptor is passed but that is not necessarily the case. The
caller can only safely assume this if the call is made from another RPG
procedure or a CL procedure.
4) Passing by value causes an extra variable copy which is performed as a
result of low-level parameter passing and is independent of the languages
used to generate the caller/callee code (via their respective compilers).
This data copy is performed "in addition" to any copying performed by the
caller code.
5) For dynamic program calls, the call to the PEP passes an array of
pointers plus an element count. For bound calls (including the call from the
PEP to the UEP) the parameters are passed individually and the value
retrieved from %parms() within a subprocedure is the total number of
parameters passed (*OMIT counting as a parameter and *NOPASS not).
6) The call to %parms() within a subprocedure is actually an attempt to
retrieve the minimal operational descriptor set by the caller (see 3 above).
In some cases this may not necessarily contain a valid value. If the caller
is a RPG or CL procedure then this value will always be set and will be
valid.
Again, I invite correction on any/all of the above.
Also, could anybody take this thread further and explain HOW the use of
varying and/or options(*varsize) affect the efficiencies in passing large
string data. I can see the value (no pun intended) in using both of these
and I use options(*varsize) frequently in conjunction with opdesc and CEEDOD
calls. But what I'd like to know is "exactly" why varying is better than
non-varying . I can obviously see there will be efficiencies because only
the data defined by the length is copied to temporaries but I'd like to know
a little more about the mechanics of, say, passing a varying character
string by value.
Also, as the return variable is aIways passed by value I would like to know
whether it is also subject to the low-level extra copy described by Barbara.
I know this was described as a low-level parameter passing function by the
OS, but I'd be interested to know if this applies to return variables too.
I'd also like to know if the passing of the return variable is subject to
the same casting/truncating/padding rules as parameters?
Finally, are there any books/ebooks/redpapers/whitepapers/manuals which
describe this mechanism. As this is architectural and not language specific
I can't imagine that any RPG-specific manuals would do it justice.
Cheers, and thanks for all of your input so far.
Larry
midrange.com
