RE: CONST Parameter passing, varying and *varsize

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob Cozzi
> Sent: Friday, May 05, 2006 3:36 PM
> To: 'RPG programming on the AS400 / iSeries'
> Subject: RE: CONST Parameter passing, varying and *varsize
> 
> Good questions. I've had those recently myself.
> The compile will create a temp variable for literals and 
> things like that and
> then reuse that temp variable. By "temp" I think we mean 
> "work field". 
> So for example, if it needs a 200-byte field in one instance 
> and a 14-byte field
> in anther, it'll reuse that 200-byte field.

That makes sense.

> If a variable is passed to a OPTIONS(*VARSIZE) CONST parm and 
> that variable is
> equal to or longer than the parm def, it'll get passed directly.
> If the variable is shorter, a substring-like function is used 
> to pass the data
> or another temp variable is created.

I don't understand this, I thought when passing a variable as CONST
OPTIONS(*VARSIZE) parameter, the variable was always just passed
directly.  No temporaries ever needed.


> If a literal is passed, it is copied to a temp variable and 
> that temp variable
> is passed. The only guarantee is that the temp variable in 
> this case will be
> large enough to hold the literal.

Ok, makes sense.  But is it safe to say that if a temp variable is
created as opposed to reused, it is only big enough to hold the literal?

> 
> For CONST VARYING, if the value being passed is also a 
> varying, then...
> If the variable being passed is longer than the parm def, it 
> is passed directly.

Ok, makes seems to make sense.  But what happens when you use %len() on
the parm?  Say the parm is defined as varying(10), and you pass a field
defined varying(20) and the current contents of that field is 'This is a
test.' which is 15 char's long.

If the address of the varying field is passed directly, then the first
two bytes would indicate a %len of 15.

Wouldn't it have to copy it to a work variable defined varying(10)?

> If the variable being passed  is shorter it may or may not be 
> copied to a temp
> variable.

Not sure this makes sense.  It's the way it seems like it should work,
but that means that a CONST with a varying length field works different
that CONST with a fixed length field.  With fixed lengths fields, the
compiler would always copy to a work variable of at least the same size
as the parm def.

It would work even with the mismatch in allocated lengths since 
1) the parm is CONST and can't be changed.
2) the parm is VARYING and so at runtime, you can use more than what's
in there.

> If a literal is being passed, it is copied to a temp variable 
> that may be up to
> the length of the parm def, but it could be longer or shorter 
> than the parm def,
> depending on a number of things.

What are the number of things? Assuming there's no temp variable to
reuse, and no other need for the temp variable, it would seem that the
smart thing to do would be to create a temporary varying field of %size
== the SMALLER of %size('literal') or %size(parm).  

I was going to say larger, but looking back at my questions concerning
passing a variable declared larger than the parm, it would seem smaller
would make more sense.

Again though, this means a CONST with a varying length field works
different than a CONST on a fixed length field.  With CONST on a fixed
length field, the literal is always copied to a temporary field of
%size() == %size(parm).


Thanks,
Charles Wilt