Re: Stacking data structures

[Scott Klement <klemscot@xxxxxxxxxxxx>]

I'm not sure that this code would do what you expect it to...   the INZ()
keyword would (if it compiled) give your pointers their initial values.
All of them would be set to *NULL, since they're all (indirectly)
referencing the same area of memory as pOBJL0300 which starts as *NULL.

However when you change the value of pOBJL0300, the other pointers WOULDNT
change unless you explcitly changed them.   Remember that INZ() only sets
the value of something at program startup!  This probably isn't what you
meant to do...

What you probably wanted to do is have all of the data structures be
based in the same area of memory, so that when the address of one changes,
they all change.

In your example, you could simply base all 3 data structures on the
same pointer.   This would make them all refer to the same area of
memory.  When one DS has it's address changed, they all get changed.

This works because the OBJL0100D, OBJL0200D fields are both at the
start of the larger data structure, so they are in fact at the same
address in memory as the larger data structure.

Of course, if your "sub-data structures" (for lack of a better term)
didn't go at the beginning of the larger data structure, this method
wouldn't work, you'd have to use some other options:

    1) You could put some "padding" at the beginning of the "sub-data
           structure" so that it's subfields would be offset down a
           few bytes.   That way, you could place your sub-ds in the
           same area of memory as the main DS, and use the same pointer.

    2) Each time you changed the address of the main DS, you could also
           change the address of the sub-ds.  For example:

           eval ptr1 = some allocated memory
           eval ptr2 = ptr1 + 151

           would place the "sub-ds" based on ptr2 at position 152 of
           the larger DS based on ptr1.  Remember that each time you
           changed ptr1, you'd also have to change ptr2 accordingly.

    3) You could use the traditional (and less confusing) method.  Use
           the OVERLAY keyword to put the fields of OBJL0100, OBJL0200
           and OBJL0300 all into one data structure.

I don't really think that the issues you encountered are "bugs" per-se,
but I'll let one of the IBMers address that :)



On Tue, 18 Sep 2001 rob@dekko.com wrote:
>
> Because of the many possible formats you can use on some of the list API's
> we thought of stacking data structures.  Below is a sample:
>
>       * OBJL0100 - QUSLOBJ - List Objects - Object names
>      D pOBJL0100       S               *   Inz(%addr(OBJL0100D))
>      D OBJL0100        DS                  Based(pOBJL0100)
>      D  OLObjNam                     10A
>      D  OLObjLib                     10A
>      D  OLObjTyp                     10A
>
>       * OBJL0200 - QUSLOBJ - List Objects - Text description and extended
>      D pOBJL0200       S               *   Inz(%addr(OBJL0200D))
>      D OBJL0200        DS                  Based(pOBJL0200)
>      D  OBJL0100D                          Like(OBJL0100)
>      D  OLObjSts                      1A
>      D  OLExtAtr                     10A
>      D  OLTxtDsc                     50A
>      D  OLDefAtr                     10A
>      D  OLRes1                        7A
>
>       * OBJL0300 - QUSLOBJ - List Objects - Basic object information
>      D pOBJL0300       S               *
>      D OBJL0300        DS                  Based(pOBJL0300)
>      D  OBJL0200D                          Like(OBJL0200)
>      D  OLAuxSP                      10I 0
>      D  OLObjOwn                     10A
>      D  OLObjDom                      2A
>      D  OLCrtDat                      8A
>      D  OLChgDat                      8A
>      D  OLStorage                    10A
>      D  OLCmprSts                     1A
>      D  OLAlwChg                      1A
>      D  OLAudVal                     10A
>      D  OLRes2                        9A
>
> But, when we compile this we get
>  Msg id  Sv Number Seq     Message text
> *RNF0314 20      7 000200+ Built-in function %ADDR(OBJL0100D) does not have
> a value
>                            known at compile-time; built-in function is
> ignored.
> *RNF0314 20     14 000900+ Built-in function %ADDR(OBJL0200D) does not have
> a value
>                            known at compile-time; built-in function is
> ignored.
>
> So we tried to cheat and changed a few lines:
>      D pOBJL0300       S               *
> became
>      D pOBJL0300       S               *   Inz(%addr(OBJL0300P))
> Ptr object list
> and we added
>      D OBJL0300P       S              1A
> and got the same results.
>
> I)  Should I try reporting this as a bug?
> II)  Any suggested workarounds?
>
>
> Rob Berendt
>