Re: data structure overlay question.

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Barbara,

You wrote:
>Simon, "*next" _could_ have meant "after the most recent one", but
>in fact it means "next available".  By the way, you don't have to
>specify a length for DSDATA - leaving out the 159 would make your
>work-around less clumsy.

Yes, I'd forgotten about that (VRM440?) enhancement.  I initially coded:
DDSINPUT        E DS                  EXTNAME(DSUPDPAG)
D DSDATA                              LIKE(DSINPUT) overlay(DSINPUT)

to see what happened and received a compile error due to a cyclic
reference.  Not surprising!  So I just wacked the length in without
thinking.  That's what happens when you start targetting multiple
releases -- lowest common denominator.

>From the desolate RPG reference:
"Specifying OVERLAY(name:*NEXT) positions the subfield at the next
available position within the overlaid field."

OK, so it's WAD.  However, that sentence is not sufficiently clear to
make the distinction.  And you omitted the rest of the paragraph which
states:  "(This will be the first byte past all other subfields prior to
this subfield that overlay the same subfield.)" which implies that it
WILL be 'after the most recent one' for that subfield.

I realise that DSINPUT is a DS and DSDATA is a subfield but I fail to see
any fundamental difference between DSINPUT and DSDATA in this case.  If I
overlay DSINPUT at position 1 for a length of 10 then the next available
position over DSINPUT is 11.  So I experimented a bit and found:

D               DS
D  telephone
D    area                         3     overlay(telephone)
D    exchange                     3     overlay(telephone:*next)
D    phone                        5     overlay(telephone:*next)

and

D  telephone    DS
D    area                         3     overlay(telephone)
D    exchange                     3     overlay(telephone:*next)
D    phone                        5     overlay(telephone:*next)

behave identically and as expected.

I then created an external DS with a single 11 byte field.

A          R FORMAT
A            DATA          11

And coded

D telephone     E DS                  EXTNAME(phoneds)
D    area                         3     overlay(telephone)
D    exchange                     3     overlay(telephone:*next)
D    phone                        5     overlay(telephone:*next)

The behaviour is as Richard found.  The 'problem' is because RPG allows
you to tack subfields onto the end of an external data structure so in
this case the additional subfields are added to the end of the structure
derived from the external file.

The external definition creates a DS with a single 11-byte subfield
called DATA, adds an overlay for AREA over DATA because an OVERLAY
without a position assumes position 1, then it treats the *NEXT subfields
as if they had been coded explicitly at the end of the external
definition.  So we get a structure that looks as if it had been coded as:

D telephone     E DS                  EXTNAME(phoneds)
D    data                        11
D    area                         3     overlay(telephone)
D    exchange                     3
D    phone                        5

If this had been explicitly coded it would be obvious that the programmer
intended EXCHANGE and PHONE to be tacked on to the end of the external
definition.  In the overlay example we are discussing that is not the
case.   The programmer intended the fields to overlay the structure.  It
appears that the external field definitions implicitly result in an
overlay(*NEXT) on the DS name prior to the programmers first use of that
construct thus throwing the expected calculation of *NEXT out of whack.

The current behaviour is a function of:
        a) allowing the DS to be directly overlayed
        b) allowing the compiler to calculate *NEXT position
        c) allowing additional fields to be added to the end of an
external DS

I got to this point thinking that the current interpretation of OVERLAY
when used with an external DS is wrong and should be changed.  But,
thinking further I tried:

D telephone       DS
D   area                         3    overlay(telephone)
D   other_stuff                 10
D   exchange                     3    overlay(telephone:*next)
D   phone                        5    overlay(telephone:*next)

And now I find that it is at least consistent, fits the quoted
documentation, and helps explain the behaviour found by Richard.
EXCHANGE and PHONE will be added after OTHER_STUFF and does actually make
sense -- although may not be what was intended by the programmer.  It
effectively means that OVERLAY(*NEXT) is ignored when overlaying the DS
name and that makes me think OVERLAY(*NEXT) should be interpreted as
"after the most recent one" which is probably what most programmer's will
expect.

The ability to overlay the DS directly is relatively new (also VRM440 I
think) and so will only affect new code but 440 was a while ago now and
it may be difficult to change this behaviour.  I guess we're stuck with
WAD and this is simply an idiosyncrasy we'll have to put up with.
Hopefully the above will help others understand what is happening with
the storage definitons in these cases.

>A good question.  I've added this to our list of possible future
>enhancements.

Excellent!

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------