Re: Passing an array overlay as a parameter -- RPG400-L

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, parametersare passed by reference. Reference means "a pointer is passed" or ifyou're not familiar with pointers, there's a different way of looking atit: It puts the variable from the subprocedure in the same area of memoryas 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 30bytes of the memory space belong to the Fky#Fky array. Then it skips abyte. Then there's another 30 that belong to the Fky#Fky array, then itskips a byte, etc.

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

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

Incidentally, this has nothing to do with subprocedures -- if you called aprogram, instead of a subprocedure, you'd have the same result. You couldreproduce 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 contiguousarray, and then passing that. You're no longer referencing the one that'snot 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 thesubprocedure to view the contents of memory at the same location that thecaller views.

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

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

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


     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 datastructure so that you get the alternating keys/switches in the samememory. For example:

  http://code.midrange.com/index.php?id=496e169812