Re: Procedure parameter with VALUE option

[bmorris@xxxxxxxxxx]

>From: "Peter Dow" <pcdow@yahoo.com>
>Date: Thu, 13 Dec 2001 14:32:53 -0800
>
>Thanks for jumping in.  You're saying that when I use VALUE, it just
copies
>the entire value on the stack?  No conversion takes place as with CONST?
> ...

Peter, conversion is done if necessary.  The value is put on the stack as
dictated by the parameter's type in the prototype.  It's convenient to
think of the compiler having a temporary of the prototype-type, and
EVALing the passed parameter to this temporary, then copying the temporary
to the parameter stack.  (A temporary may or may not be involved - some
conversions can be done "on the stack", but the effect is the same.)

I can't explain your debug session output.  Are you sure sure sure that
those are the correct prototypes?  Could you try again with a DBGVIEW
(*LIST)
and do your cut-and-paste from the debug listing?  (For both the caller
and the callee - show us both prototypes as they appear in the listing,
while you're debugging.  Also show the PI as it appears in the debug
listing.  Do the EVALs again, and post the hex value.)

Are you sure the calling procedure and called procedure are working from
the same prototype?  It looks to me like the caller thinks the parameter is
shorter.  And/or that one has VARYING and the other doesn't  RPG's
parameter
checking only works at compile time - if you change the prototype and only
recompile one, bad things will happen.  Or ... shudder ... if you have the
prototype coded in two different places and forget to update one ... then
... no, I can't speak of this abomination any further.

Here's a little summary of parameter-passing lore.  Not to replace reading
and re-reading of the section in the programmer's guide called "Passing
Prototyped Parameters".

VALUE     copied to stack in form required by prototype (some
          conversions may be done).  If parameter is changed,
          the change is not seen by the caller.  EVAL rules
          apply when conversion is done.
VALUE OPTIONS(*STRING) (for pointers only)
          if character data is passed, data is copied to a
          temporary with x'00' appended, and a pointer to the
          temporary is passed
CONST     pointer passed on stack.  If passed parameter is
          not exactly the right type, a temporary is created
          and the passed parameter is assigned to the temporary
          using EVAL rules.  Compiler doesn't allow the parameter
          to be modified within the procedure.
---       no keyword required for "by reference".  Pointer is
          passed.
VARYING   applies to both VALUE, CONST and reference, as well as
          to standalone fields, subfields etc.  Character data
          is preceded by a two-byte length.  %len returns this
          length, and the length can be set by assigning to %len.
          With both VALUE and CONST parameters, the data after
          the current length is undefined.  For example, if you
          have 10A VARYING with a value of 'ABC', the only part
          of the parameter that you should consider is the first
          5 bytes (the 2-byte length and the 3-bytes of 'ABC').

          VARYING isn't really a parameter-passing option.  It's
          just a data type.  The reason it seems like a
          parameter-passing option is that CONST VARYING is
          a good replacement for OPTIONS(*VARSIZE) which IS a
          parameter-passing option.
OPTIONS(*VARSIZE)
          compiler allows a shorter parameter to be passed than
          the prototype says (or shorter/longer, in the case of
          VARYING).  The actual length must be determined by
          another parameter or by coding OPDESC on the prototype
          and calling CEEDOD within the called procedure.

          With CONST and OPTIONS(*VARSIZE), the full size may or
          may not be passed.  If the full size is passed today,
          it may not be passed tomorrow.

There are many ways to handle character parameters.  My personal
recommendation is CONST VARYING.  Passing large VALUE parameters
is always a bad idea (every language, every system).  If you
need to modify the parameter within the procedure, but the
caller doesn't need to see the change, declare a temporary and
copy the passed parameter to the temp.  Copying is cheap.

Barbara Morris