Re: Multiple occurrence data structure anomaly -- RPG400-L

Remember that only a pointer is passed. Not the data. As far as the compiler is concerned, when a MODS is passed as a parm the address used is of the current occurrence. If that is set to 1 and and the called routine manipulates the OCCUR instance then a change to instance 2 will be seen by the caller as being in instance 2. However - if the occurrence number is set to (say) 4 at the time of the call and the called routine advances the occurrence to what it views as instance 2, that would be seen back in the callee as appearing in instance 5.

MODS are a horrible old relic of the past - try not to use them in new code.

Occurrence 51 was previously some other variable in your program - possibly even an RPG compiler generated control variable. Doing this in production code will (and has) caused disastrous results.

The only "safe" way to handle a MODS in a called program is to either:

a) Set occurrence to 1 before passing the MODS or

b) Pass the MODS as-is and make certain to _never_ manipulate the occurrence in the called routine.

On 2013-07-05, at 9:54 AM, "Briggs, Trevor (TBriggs2)" <TBriggs2@xxxxxxxxxxx> wrote:

Barbara,

You say:
" When you pass a MODS as a prototyped parameter, it passes the current
occurrence. (As you've seen.)"

What I interpret you are saying is that ONLY the current occurrence is
passed. Yet in practice, I see that if Pgm B populates occurrences 1 and
2, then Pgm A sees this on return. What is apparently happening is that
the whole MODS is being passed (at least, is being returned), but
"positioned at" the current occurrence.

What I find really odd is that without the setting of the occurrence to
1 before the call, when Pgm B populates occurrences 1 and 2, Pgm A sees
the results in occurrences 50 and 51 - of a 50-occurrence MODS! (This is
observed by investigating the MODS with Debug - i.e. eval
MYMODS(50..51). Attempting to access occurrence 51 in the program
generates error RNX0122: OCCUR value is out of range, as one would
expect.)

Curious!

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Wednesday, July 03, 2013 9:42 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Multiple occurrence data structure anomaly

On 7/2/2013 2:46 PM, Briggs, Trevor (TBriggs2) wrote:

...
When control is returned to Pgm A, value is in
occurrence 50 of the MODS.

When you pass a MODS as a prototyped parameter, it passes the current
occurrence. (As you've seen.)

I assume you didn't add the DIM keyword for the prototyped, so I think
it makes sense that it would pass the current occurrence.

Just by the way, if you use an array of data structures (DIM keyword
instead of OCCURS keyword), you can distinguish between the whole array
ARR, and an element ARR(i).

For sure I would recommend using a DS array for new code, since it's
easier (I think) to code array indexes than to manage occurrences.

But for existing code, it's not usually easy to change a MODS to a
DS-array, since it involves changing every reference to the subfields.
For example, if a MODS named INFO was previously not qualified, and INFO

was changed to a qualified ds array, the reference to subfield ADDR
would change from simply ADDR to INFO(index).ADDR.

--
Barbara
--
This is the RPG programming on the IBM i (AS/400 and 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.

************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information which may be confidential or privileged and is intended only for the individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message.
All personal messages express views solely of the sender, which are not to be attributed to Lincare Holdings Inc., and may not be copied or distributed without this disclaimer.
If you received this message in error, please notify us immediately at MailAdmin@xxxxxxxxxxx or (800) 284-2006.
************************************************************************************************************************************************************************************************************

--
This is the RPG programming on the IBM i (AS/400 and 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.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com