From: Barbara Morris
Yes, %parms is literally the number of parms passed, *OMIT is counted,
*NOPASS is not. %parms is handled by the operational descriptor. Even
if you don't code OPDESC, RPG passes a "mini" operational descriptor
that gives the number of parameters. CL does too. C, C++, and COBOL
don't do this unless you tell them to, so if you call an RPG bound
procedure from these languages without requesting the operational
descriptor, %parms will be meaningless. And there is an API that will
make a bound call to a named procedure in a named service program; it's
not even possible to request that the API pass the operational
descriptor, so %parms can never be used in a procedure that might be
called by that API (I forget its name).
Wonderfully described as usual, Barbara. Of course, I often require a
second pass <grin>.
Let me make a couple of quick statements to be sure I'm clear. If I'm
wrong, I'm hoping you'll point them out gently.
Okay, first I see basically two kinds of calls in the world, calls to
programs and calls to procedures. I get a little fuzzy on the difference
between a bound procedure and a procedure in a service programs; as far as I
can tell, the difference lies more in the resolution of the procedure
address than in the parameter passing.
Second, in calls to an RPG program, the number of parms in the program
status data structure is the same as the value in %parms (and I have been in
fact replacing the PSDS with %parms in my own code).
But now you throw a tiny wrench into this for me. While I rarely use C or
C++, I've run into more COBOL lately and the way I read what you said, you
need a special syntactical construct to allow COBOL to populate the %parms
variable properly is a COBOL program calls an RPG program. And I assume
this would also apply to procedures.
As I read what you've written, in those cases where you either don't or
can't pass operational descriptors, %parms is meaningless; but does it get a
value? Here's why I ask: if it at least gets set to the maximum number of
values in the parameter list, then I could make an architectural decision
that all calls that don't use OPDESC must simply include all parameters, and
the called procedure would still work. Whereas if %parms is truly undefined
(or always zero, or something like that), then I would either have to always
call variable parameter procedures with OPDESC (in particular taking care on
COBOL calls) or else somehow test in the called procedure whether OPDESC was
used at all (and I don't even know if that's possible, nor what sort of
overhead it entails).
Does that make sense?
Joe
midrange.com
