Re: VARYING, options(*varsize) and exit point programs

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hi Rob,

On Thu, 13 Mar 2003 rob@xxxxxxxxx wrote:
>
> However, the variable USRIN seems to contain the values for several of the
> other variables.  These other variables not only appear in USRIN, but also
> appear in their respective variables.

Let me try to get you thinking about this in the same way that I do...
What is a parameter?  When a parameter gets passed, what REALLY happens?

Unless a parameter is explicitly coded as "VALUE" it's contents are passed
by "reference".  This means that the calling program finds the address (in
memory) to one of it's variables and copies it to a place where the
program that it's calling will retrieve it.

What good is this?   Well, if you know the address of a variable, then you
can read & write from that area of memory.   This allows communication
from program to program or procedure to procedure.   Since they're using
the same area of memory, changes made to the data at that address affect
both programs.

Great.   So, now that we know that, how does options(*varsize) work?

Well, options(*varsize) does nothing but relax validity checking in
the compiler.   Without this keyword, the calling program must supply at
variable that's at LEAST as large as the one in the prototype.    But,
when you use options(*varsize) it no longer checks for this.
That's ALL it does.

So, when the calling procedure passes a 10-byte variable, and the
receiving procedure has a 50-byte parameter defined, what is located in
those extra 40 bytes?

The answer is:  whatever happens to be in the memory that follows the
caller's variable.   Could be anything.

In your case, it sounds like the caller is allocating memory for the
various parameters so that they happen to be right next to each other.
Therefore, you happen to see the contents of the subsequent parameters
in the first parameter.    (You can't rely on this behavior, however,
unless the variables are declared in a data structure from every possible
calling program -- it's just luck that it happens to do it this way in
this release of the RPG compiler)

>
> Am I doing something wrong, or am I forced into doing something like:
>  USRIN=%substr(usrin:1:usrlenin);
>

You definitely don't want to do that!   What does that do?   It wipes out
everything in USRIN past the position referenced by usrlenin.   Since
the memory that's past usrlenin is being used by other variables,
you'd wipe out the contents of those variables.

First of all, remove "VARYING" from your prototypes.   Unless this is
something new, exit programs don't pass VARYING variables.   That means
the contents of the first two bytes of their string is being interpreted
by your program as a length.   That's not good.

Next, only reference the part of the variable that they're telling you
is passed.   In the example above, whenever you reference USRIN, you
should reference it as %subst(usrin:1:usrlenin).   For example

               if %subst(usrin:1:usrlenin) = 'ROB'

               or

               %subst(usrin:1:usrlenin) = *blanks

I'm really trying to stress this, so I'll say it again:  Make sure you
never touch any part of the variable past the "usrlenin" position.

I know this message was long, but I try to explain WHY things happen, not
just how to fix them.  Hopefully this knowledge will help you when you do
more things using parameters down the road.