RE: INFDS layout for Display Files

Jon Paris said:

>Why not simply specify one of the DSs to
>the INFDS keyword and make the second
>structure BASED on a pointer to the
>first structure?

Oddly, RPG won't let me POST to a DS that isn't referred to on an F spec
INFDS().  I wish I understood the reasoning behind this...

>If you need to preserve the data from
>one format when retrieving the other
>simply copy it to another field or DS.

This is the same scenario whether you use BASED or not.  Only one of the
structures has the 'right' data, depending on whether the POST has been
processed or not (because they share the same memory space.)

     fRPGIV     cf   e             workstn infds(displayDS)
     d displayDS       ds
     d...

     d displayPost     ds                  based(infdsPtr)
     d...

     d infdsPtr        s               *   inz(%addr(displayDS))

Before POST, 'displayDS' has the 'right' data in 241-344 and 'displayPost'
has the 'wrong' data.  After POST the situation is reversed.  As Jon says,
you need to save the data structure you're interested in for later
reference.  This requires the above shared definitions and another pair NOT
shared.  I'd write a sub-procedure that lets you save the INFDS you're
interested in, but you must now keep in mind that this 'saved' structure is
no longer current!  Probably, you want to wrap your I/O inside a
sub-procedure that does the I/O AND saves the correct INFDS so you don't
ever refer to a stale copy by accident.

All in all, it seems more work than is needed for that POST data.  Aside
from the acquired and invited statuses and the data available flag, the rest
of the POST data is static.  Can you do a POST immediately after opening the
display file, save the data you need and then use the normal INFDS the rest
of the time?

  --buck

"This box Rocks!" - related to 2002 NE IBM
Conference attendees by IBM's Stephanie Joy