RE: Passing an array overlay as a parameter

Scott,

I appreciate the response.
I guess I was thinking the Overlay was similar to the Alt keyword in
that it created it's own space in storage, but I now realize (after
reading your email and from perusing the Reference manual) that I was
mistaken.

Thanks,
 
Kurt Anderson
Application Developer
Highsmith Inc

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, August 09, 2005 11:34 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Passing an array overlay as a parameter

> When I step into the $LoadKeys procedure, though, and I see what the 
> values of those arrays are, the FKy#FKy array includes the switches.
> The FKy#Swtch array evaluates to "1F2=Continue    ".

Unless you explicitly put the word "VALUE" on the prototype, parameters
are passed by reference.  Reference means "a pointer is passed" or if
you're not familiar with pointers, there's a different way of looking at
it:  It puts the variable from the subprocedure in the same area of
memory as the variable from the caller.

Can you see why that creates a big problem?

The variable you've declared in the caller isn't contiguous.  The first
30 bytes of the memory space belong to the Fky#Fky array. Then it skips
a byte.  Then there's another 30 that belong to the Fky#Fky array, then
it skips a byte, etc.

However, in the subprocedure, you've defined an array where it expects
each group of 30 bytes to come immediately after the previous bunch of
30.

So, putting them in the same area of memory WON'T WORK... you'll end up
with a mess.

Incidentally, this has nothing to do with subprocedures -- if you called
a program, instead of a subprocedure, you'd have the same result.  You
could reproduce this problem in RPG III if you wanted to.

> If I move the arrays into intermediate arrays, which I then pass to 
> the procedure, then it works.

That's because you're copying the non-contiguous array into a contiguous
array, and then passing that.  You're no longer referencing the one
that's not contiguous in the subprocedure.

> Why is it passing a value to the procedure that is different than what

> I see in the program when I'm in debug (Optimize *None).

It's not passing a value at all.  It's passing a pointer, that causes
the subprocedure to view the contents of memory at the same location
that the caller views.

Since that area of memory contains switches interspersed with labels,
you get them both in the subprocedure as well.

One easy solution to the problem is to pass the arrays by VALUE instead
of CONST.  That way, it'll make a copy of them (just as it does when you
use the intermediate array) and you won't have a problem -- of course,
this solution operates at the expense of performance.

Here's the PR with the VALUE keyword. (You'd have to change the PI as
well:)

      D $LoadFKeys      PR
      D  FKY#FKy                      30a   Dim(24) Value
      D  FKY#Swtch                     1a   Dim(24) Value
      D  FKY#SFLPag                    1p 0         Const
      D  FKY#Ldd                      78a   Dim(12)

An alternative that would perform better would be to pass the entire
data structure so that you get the alternating keys/switches in the same
memory.  For example:
   http://code.midrange.com/index.php?id=496e169812
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.