Re: Is const really that much better than value?

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