Re: Multiple occurrence data structure anomaly

On 7/5/2013 1:53 PM, Briggs, Trevor (TBriggs2) wrote:

I find it hard to accept that "There is absolutely, positively no
difference in the way params are handled between RPG III and RPG IV."
when the observed behavior seems to disprove this. In both instances,
the programs were passing occurrence 50 of a MODS to a second program.
The second program populated occurrence 1. When first program was OPM it
found occurrence 1 populated. When the first program was ILE it found
occurrence 50 populated. Something is different somewhere!

You're right. There is a difference, but it's not a difference between RPG III and RPG IV.

It's a difference in the way RPG IV passes a MODS with the PARM opcode vs a prototyped call. The prototyped call only passes one occurrence, and the called program should only be working with one occurrence. The prototyped parameter doesn't have the DIM keyword. Even if you define the parameter LIKEDS(MODS), it is just defining the parameter as an ordinary data structure, not an array. LIKE and LIKEDS don't inherit DIM or OCCURS.

The PARM opcode is handled identically in RPG III and RPG IV; it passes the address of the first occurrence.

When the calling programs are using the PARM opcode, and the calling program has the current occurrence set to 50, it is not passing occurrence 50, it is passing occurrence 1, or more exactly, the address of occurrence 1. It does this without changing the occurrence number in the calling program - the RPG compiler can generate code to access either the current occurance or the beginning of the MODS without actually changing the occurrence number.

Interestingly, in both RPG III and RPG IV, if you pass a subfield of a MODS, it passes the subfield of the current occurrence.