Re: DS fields

John/Mark,

Mark said:

>> How difficult would it be to allow a field to be defined in multiple DSs,
>>so that it would point to the same area in storage ?

Could you clarify exactly what it is you want to be able to do?
Reading this at face value, it sounds not only difficult but
technically impossible.  So I must misunderstand what you mean.

A data structure, by definition, lets you control the memory
allocation of subfields.  That is precisely what they are good for,
and to be able to then manipulate the grouping as a whole.  

So if a one DS had a given field as (for example) its third subfield,
how could that same area in storage also be in another DS with
different subfields surrounding it?

If you don't base a DS on a pointer or name the DS as a *Entry parm,
each DS has its own memory space so subfields could not possibly refer
to the same memory location.  If you base a DS on a pointer, then you
can have multiple DS's with subfields referencing the same area in
storage.  But I don't think this is what you are asking for.

John said:

>I asked for this about 6-8 years ago.    I believe (can anyone verify this)
>that you could do that
>with RPGII on the Sys/34-36.    

Incorrect.  If the same subfield name appeared in multiple DS's on the
S/34/36, it would generate a warning error for a multiply-defined
field.  All but the first DS definition were ignored. The other DS's
would be large enough to contain the subfield, but program references
to the subfield name would refer to only the first DS occurence.

If a field was defined both in a DS and as a regular input field or as
a C-spec result field but with different attributes (length or decimal
positions), it also generated the same warning message.  What the
compiler assigned was the first definition in a DS (if any).  If the
same fieldname was used multiple times but was not in a DS, it was
given the attributes of the first definition found.

>It kinda happens now already if you think about it, If a field is on a DB
>file, DSP file, and a D/S  
>It's almost like having three different quasi structures with the same
>variable name with 
>the same value.   Right ?

No.  In this case there is only one "structure", the DS.  There is
only one variable with one value.  DB or Dspf I/O references the
subfield contents of the DS to get or put the field value in the file
buffer.

RPG is atypical compared to some (most?) languages in how it handles
the same field name occuring in multiple files or record formats.  Are
you perhaps from a COBOL background or other language where you used
qualified fieldnames?

>The pain is having an Externally defined DS and wanting to use that same
>field in another
>structure and have them all stay in sync.

If you can get by with just one DS (say the DB record format), and let
the Dspf/Prtf use some of the same fieldnames but not also make them
an externally defined DS, then RPG handles it nicely.

If for some reason you must make the DB, Dspf, and Prtf record formats
all be externally defined DS's and they use the same fieldnames, then
you must use the Prefix() keyword to make the fieldnames unique.
There is no equivalent to Cobol's "Move corresponding" verb since RPG
does not use qualified fieldnames.

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