Re: Parameter passing RPV III <--> RPG IV vs. RPG IV <--> RPG IV

Hi Charles,

[SNIP]
> We converted this program to RPG IV using CVTRPGSRC.  During the first use,
> it went into an endless loop.  While debugging, we realized that the P@ERR
> parameter in the called program was 3 chars long and not 1.  All zeros meant
> no error, while anything else ( '001', '002', '003',...'006') would be an
> error.
[SNIP]

You should be very careful to make sure that the original source of the
parameter (in this case, the program making the call) passes at LEAST as
many characters as the called program receives.

I'll explain more below.

[SNIP]
> Now the question: we know that the RPG III program has worked in the past
> when invalid data was passed to CADATE, we don't understand why it would
> have failed as an RPG IV program; particularly when the fix was to change
> P@ERR to 3 chars and the comparison to '000'.  Unless the mismatch in the
> parameters had a different effect with an RPG III <--> RPG IV call than they
> did with a RPG IV <--> RPG IV call.  It almost seems as if the RPG III P@ERR
> ended up with the rightmost char and the RPG IV P@ERR ended up with the
> leftmost (as I would expect).
[SNIP]
> So what the heck was going on?  Thoughts?

First, RPG III and RPG IV use the exact same mechanism for passing
parameters -- the version of RPG isn't the problem.

Let's start with the basics:

What is a variable?  A variable is a "view"  of a particular area of your
computer's "main storage" (in most cases, RAM).   Data in RAM is always
stored in bytes, but how those bytes are interpreted by your program
depends on the variable's type and length.

How do parameters work?  The program making the call copies the memory
address of each variable that's to be used as a parameter onto a stack.
When the called program runs, rather than ask the operating system for
memory (as it normally would for a variable) it uses the address from the
stack.

In other words, the parameter in the called program is still a "view" of
memory -- but it's the CALLER'S memory instead of it's own.

In your example, your program has a 1-byte field that it passes.  The
called program has a 3-byte field starting at the same address in memory.
The extra two bytes in the field are viewing whatever memory happens to be
right after the caller's 1-byte.

Perhaps in your particular RPG III program, it happens to always store two
zeroes after your 1-byte field.  If so, you got lucky.  But, don't start
thinking that the RPG III program somehow magically knew that you wanted
zeroes in that particular space in memory!  You just got lucky, that's
all.

If you had been unlucky, that particular area of memory may have belonged
to a different program.  Or, even a different job!   If that had been the
case, you could've had some serious problems.  And thats why you need to
make sure that the program that requests the memory from the OS always
requests at LEAST as much memory as the callers will use.  You can request
MORE by declaring the variable larger -- but never less, or you'll have
sporadic problems.