Re: Varying fields as parameters on procedure calls.

On 13-Apr-2015 08:26 -0500, Charles Wilt wrote:

On 12-Apr-2015 00:31 -0500, Alan Campin wrote:

On Sat, Apr 11, 2015 at 9:47 PM, Scott Klement wrote:

On 4/10/2015 6:13 PM, Alan Campin wrote:

Just a quick question. I was reading on article on the web
and it stated that if I had a varying fields that what would
get passed by VALUE would be just the first two digits for
the length and the actual length of the data.

It has always been my understanding if I had field that was
64K varying and I passed it as a parameter that the 64K plus
two (or four) bytes for the length is what would be passed
even I only had say 10 bytes of data.

Since a statement like InParm = *ALL'*'; is valid even
though it would never be seen by the caller, I don't see any
other way it could work except to the pass the entire length.
<<SNIP>>

Can you point to this article you're referring to? I'd like to
understand what you're referring to.

There's nothing magic about VARYING data types -- they work the
same as any other data type. When you pass by VALUE the variable
is copied -- the whole thing is copied, so if you had 1000A
VARYING, it'd copy 1002 bytes from the caller to the procedure.
When passed by reference (i.e. no VALUE keyword) than a pointer
(16 bytes) is passed instead, and it shares the same memory as
the caller. <<SNIP>>

Old article by Bob Cozzi and now I can't find it again. Maybe
somebody else can find it.

I wrote a test program and proved that it [is] sending the whole
thing. I passed a 64K varying string by value a million times and
then ran the same thing passing the string by using *STRING and
*TRIM and basically it was 38 times faster. The *STRING was passing
the actual 17 bytes and the by Value was sending the whole 64K each
time so basically I answered my own question. I know it always
passed the whole thing but Cozzi was saying that it only passed the
actual length which made no sense to me.

Perhaps Bob was talking about how it works when you pass in a
literal..

myproc('Hello');

If the parm is defined as CONST VARYING, I know the above generally
creates a temporary variable of size 5 + 2 = 7 and passes that into
the parm.

It wouldn't surprise me that VALUE worked the same way.

Note I say generally. Per Barbara's point in this thread
<http://archive.midrange.com/rpg400-l/200605/msg00162.html >

The compiler will try to reuse temporary variable, so if there's an
existing one bigger, it might reuse that instead of creating a new
one.

I think the salient point is that the varying /value/ copied onto the stack [per passed by-value] must be stored within a contiguous memory location of a length matching the maximal-length of the storage required for the declared\prototyped parameter *because*, as reminded in the OP, the passed by-value data for that parameter is supported to be referenced as though the parameter is a _local variable_ within the called procedure. The parameter prototyped with CONST is prohibited from change by the invoked procedure, but the parameter prototyped with VALUE is *not* prohibited from change by the invoke procedure, although any changes should not be visible to the invoker; i.e. the alluded operation of EVAL InParm=*ALL'*'; if performed by the invoked procedure would corrupt memory *if* the RPG run-time were ever to pass less than the maximum storage for the /value/ copied onto the stack, because the invoked procedure would operate against the parameter as declared locally [filling to the maximal length with asterisks] despite the run-time having allocated only a portion of the declared storage against which the invoked procedure could safely operate.