Re: DS fields

Mark,

> Then why can you have an input field coming from files?

When a record format is read (DB, dspf, etc), the entire record
contents are passed to a "buffer" area.  RPG then performs implicit
moves from the buffer to the separate memory area used as working
storage for each field referenced by the program.  (With DEBUG(*YES),
all fields in the record format have working storage fields assigned
and moved.  Without DEBUG(*YES), only referenced fields are allocated
field areas outside the buffer.)  The opposite happens on an output
operation -- the fields are implicity moved to the buffer area first.

If the field name does not appear in a DS, then the field's storage
area is just like any other stand-alone variable.  It will not overlap
with any other fields.  But unlike a stand-alone field, it has
implicit moves to/from the record format buffer after a read and
before a write.

The only difference with a rec fmt's field name appearing in a DS is
that you have more direct control over the memory space which includes
the working storage copy of the field.  By putting it in a DS you can
perform tricks by subsetting, overlaying, redefining, etc the memory
space including the field contents.

It stands to follow that a field name therefore cannot be part of more
than one data structure because it must resolve to a single memory
address.

If this is still not clear, ask again.

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