RE: INFDS layout for Display Files

Nelson Smith wrote:

>OK, I RTFM'ed and it didn't help much.

Well that's why this list is here!

>So, let's say I created two files,
>INFDS_DSPF and INFDS_POST, with the two
>different field layouts.
>
>In my workstation file spec, I use the
>keyword INFDS(DSPF_IO_Info).
>
>Then, I create two data structures
>(DSPF_IO_Info and DSPF_Attribute) that
>bring in the two external file layouts.
>
>DSPF_IO_Info works like it always did,
>supplying information after each file op.
>
>Then on the POST operation,
>1.) put the Device name in factor 1,
>2.) leave factor 2 blank, and
>3.) put the alternate data structure name,
>    "DSPF_Attribute", in the result field.
>
>Is that correct?

I don't think so.  It was so much clearer before I actually started testing
this bad boy!  Firstly, you can't specify any DS for the result field - it
has to be an INFDS.  Secondly, the idea behind POST is to tell RPG not to
update the feedback data for every I/O operation - only on a POST.  That's a
performance thing.  Thirdly, it looks to me as if you can specify WHICH
INFDS to update by specifying Factor 2 or the result field.  So if you have
a dozen DB files you could tell the compiler to POST to the

INFDS associated with a file (factor 2 specified) -or-
INFDS named in the result field (data for the file associated with the named
INFDS)

Not as clear as I would prefer.

When I use POST, I always use the alternate format.  If there were some
circumstance where I needed to capture 'normal' feedback as well as POST
feedback, I would combine the two layouts in a single /copy member.

  --buck

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