Re: Is const really that much better than value?

[Barbara Morris <bmorris@xxxxxxxxxx>]

Larry Ducie wrote:
>  
> OK, I need to get this straight. When we call a ILE rpg program we don't
> work with this array directly do we? The values are put into the parms of
> the PEP. Is that right? I'm guessing that the call to the PEP is an internal
> bound call so it would work in the same way as a bound subprocedure call.
> Are there differences between the way parms are passed during a call to the
> PEP and during a call to a subprocedure?

You are right that it is the PEP that deals with the parameter array. 
But the PEP isn't the RPG main procedure; it's a compiler-generated 
procedure that gets called first when the program is called.  The actual 
main procedure is called the UEP = User Entry Procedure.  That 
compiler-generated call from the PEP to the UEP is a normal bound call.

>  
> > From this I would infer that passing long strings by value when there is a
> length mismatch will involve two copies of the data being made. The first a
> simply blind copy of the original data and the second used in casting to
> match the definition on the PR. For passing by constant reference only the
> second (casting) copy will be made. If the passed variable is much larger
> than that defined on the PR then the first copy in unnecessarily expensive
> as the second (casting) copy would simply truncate the data.

Not quite.  Any parameter casting is done by the caller.  If you pass a 
very large variable by value, it would be the first "casting" copy that 
would truncate the data, and then the second "parameter passing" copy by 
the OS would just deal with the prototyped length of the parameter.

>  
> If the variable is an exact match to the PR definition then passing by value
> would still involve a complete copy being made, but passing by constant
> reference would not because the original would be used and protected from
> changes.

Right.

>  
> Finally, how does %parms work in these cases? I assumed that %parms was
> simply a count of the elements in the array of pointers. If the parameters
> are passed individually in bound calls then there is no array and no element
> count. So is %parms literally the number of parms passed, taking into
> account of *OMIT being a passed parm and *NOPASS not? Is this the same for
> the PEP too?  

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).