× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: DS fields
  • From: dhandy@xxxxxxxxxxx (Douglas Handy)
  • Date: Tue, 13 Jul 1999 01:57:52 GMT

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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.