Re: data structure overlay question.

["Richard B Baird" <rbaird@xxxxxxxxxxxxxxxxxxxxx>]

Simon,

Thanks for the tips.

I'm on "digest mode" so I didn't get your reply till this morning.

See inline

>I think you have found a bug in the compiler.  I created a test program
>using your supplied code and used EVAL %ADDR() to check the addresses of
>the fields in the underlying data structure and the addresses of the
>fields in the overlay and you are correct in your assertion that only the
>first field is correctly overlayed.

that's the nice thing about debug - it shows you you're datastructure in
order of the fields in it.  That is what I thought was happening.

>I believe this is a bug because the following clumsy work-around causes
>the overlays to be built correctly.

>DDSINPUT        E DS                  EXTNAME(DSUPDPAG)

>D DSDATA                       159                  overlay(DSINPUT)
>D $fill1                              like(QZSESS ) overlay(DSdata)
>D $fill2                              like(QZBTCH ) overlay(DSdata:*next)
>D $fill3                              like(QZREF  ) overlay(DSdata:*next)
>D $QzAmt                              like(QZAMT1 ) overlay(DSdata:*next)
>D                                      dim(12) inz(0)
>D $QzChk                              like(QZCHK1 ) overlay(DSdata:*next)
>D                                      dim(12)

>Notice that I have inserted a field which overlays the entire DS and the
>other fields overlay that.  I didn't bother to pore over the RPG
>Reference but I can see no difference between overlaying the DS name and
>a subfield.  You should open an APAR with IBM support to get this fixed.
>(It may be Working As Designed but it sure ain't correct.)

This is what I ended up doing late last night and it worked great (except I
didn't supply a length for field DSDATA - don't like to hard code the
length of anything, and it makes it _somewhat_ less clumsy)

>However, I think a better approach would be something like the following:

>DDSINPUT        E DS                  EXTNAME(DSUPDPAG) INZ

>D @QzAmt          S               *   INZ(%addr(qzamt1))
>D @QzChk          S               *   INZ(%addr(qzchk1))

>D $QzAmt          S                   like(QZAMT1 ) based(@qzamt)
>D                                      dim(12)
>D $QzChk          S                   like(QZCHK1 ) based(@qzchk)
>D                                      dim(12)

>then simply ignore the pointers and just use the arrays as you would
>normally.

I have a few questions on this technique before I change my program.

1. the '*' in the field length implies "variable length"?

2. is it the "based" keyword on the $qzxxx that eventually defines the
length of the @qzxxx fields?

3. or is it the fact that the next field in the DS (@qzchk) starts at the
address of QZCHK1 that defines the length of @qzamt?   if so, what defines
the length of @qzchk?


>And why can't I code:

>D $QzAmt          S                   like(QZAMT1 ) based(%addr(qzamt1))
>D                                      dim(12)

>and let the compiler worry about the pointer?

don't know-seems like you should be able to, given that the code above it
works.

I hadn't used the %addr bif yet.  Couldn't think of a reason to until now.

Thanks again!

Rick