Re: DS fields

["David Prowak" <prowakd@xxxxxxx>]

> Did any of this make sense?
>
> Doug
Nice explanation.  I still have a question though.

>  Subfields are not pointers per se, they just have addresses within the
address >  space for the DS as a whole.
If that is the case, then how do you account for a field from a file that
is "sub divided" in a DS?
Ex:
File is MasterFile, opened for I/O
Field is Acct#

 D                 DS
 D  Acct#                     1      8
 D      Acct#Zone         1      2
 D      Acct#Region      3      5
 D      Acct#Territory   6      8

Read  MasterFile
Move '999'    Acct#Region
Update MasterRecFormat

In this case, a portion of the DS is altered, and the updated Acct# is
written to MasterFile.  I thought that the Acct# DS had a pointer to
the I/O buffer where MasterFile is read from & written from.
If pointers aren't used, how does this the change in the DS show
up in the change in the file?

Thanks,
Dave











----- Original Message -----
From: Douglas Handy <dhandy@isgroup.net>
To: <RPG400-L@midrange.com>
Sent: Monday, July 12, 1999 9:57 PM
Subject: Re: DS fields


> Mark,
>
> > Correct me if I'm wrong, but isn't each field in a DS a pointer to an
area
> >in memory?  So, if I have 3 fields coming from three different files and
> >are combined in one DS, changing one field will change the value of the
DS.
> > So why can't the same field be in multiple DSs?  It's just another
pointer
> >to the same area in memory, right?
>
> I'm sure Hans or Barbarra are better qualified to answer this
> question, but that is not the way I think of a DS.  Subfields are not
> pointers per se, they just have addresses within the address space for
> the DS as a whole.
>
> Think of a named DS as being one large contigious character field,
> which occupies a set amount of memory space the size of the DS.  Then
> pretend for a moment that you only had character subfields.
> Referencing a subfield would be analogous to using %subst( DS: start:
> len ) -- it has to be within the confines of the memory space of the
> DS just like you can only %subst() within the source field.  Other
> subfield types are essentially the same thing; it just provides a name
> for a subset of the bytes within the DS.  This is why modifying any
> byte within the DS allows any other named subfield which encompasses
> that byte to "see" the change.  It is physically the same byte in
> memory but allows a different name (and different data type)
> definition to the same memory address.
>
> Things get a little more complicated when you start using a DS based
> on a pointer.  In this case the DS does not have any memory allocated
> to itself, but is used as a "map" to name subfields over some other
> memory space.  This is extremely useful for stuff like trigger
> buffers, API return values, user spaces, etc.
>
> But even in that case, the subfields all refer to contigious portions
> of memory -- only the starting address is changed via the pointer.
>
> The bottom line is that, as I understand it, a subfield *cannot* exist
> in more than one DS.
>
> In part, you can thank (?) RPG's fixed-format syntax for this because
> space limitations effectively eliminated the possiblity of using
> qualified subfield names.  If we had room to qualify a subfield name
> with the DS to which we wanted to reference, then you could have the
> same subfield name appear in, for example, external DS's for a DB,
> dspf, and/or prtf.  But they would still not be the same memory
> location, and would not inherently have the same value.  But then it
> would be possible to ask for an opcode like COBOL's "move
> corresponding" verb which would allow you to refresh like-named
> subfields from another source in one easy to code (and maintain)
> operation.
>
> Did any of this make sense?
>
> Doug
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This is the RPG/400 Discussion Mailing List!  To submit a new         *
> * message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
> * from this list send email to MAJORDOMO@midrange.com and specify       *
> * 'unsubscribe RPG400-L' in the body of your message.  Questions should *
> * be directed to the list owner / operator: david@midrange.com          *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *