RE: data structure has no valid subfields -- RPG400-L


I had never even thought about it before, but I've always used this feature
of subfiles (and I do mean "feature").  It only made perfect sense to me
that it would return data from all fields on a chain or readc.  The whole
idea of the subfile is to store - at least - the key fields of the
pertinent records.  And, you wouldn't always want them input or both.

On the other hand, I've never needed to re-describe the i/o buffers in a
data structure.  Rarely have I written a program that, after i/o to a
screen - whether it be a simple format or a subfile - that I didn't assume
to have the same values of output-only fields before and after the I/O.

What about "hidden" fields?  from a cursory search of the manual below, it
appears that they would be considered i/o (both).  But I can remember using
hidden fields only in subfile records....

rick

----Original Message----
Thanks for the tip on the appropriate manual.  In section 2.2.5.2.20
Initializing Output/Input Fields, it says: "Output-only fields are not part
of the input buffer unless they are part of a subfile record, in which case
they are saved as if they were output/input fields."

I'm not sure how someone at the level of ignorance I was yesterday would
have hit on that section.  Today I just searched on "input buffer."

Let me get this straight--Is it safe to say that only file fields that make
it to a program's input buffer will show up in an externally defined data
structure?  Are there other situations like this one with display files?
"Aberration" is a nice temperate term.  I'm assuming this is a holdover
from
the days when bandwidth constraints were a lot more important.

> -----Original Message-----
> From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
> Sent: Friday, February 01, 2002 2:01 PM
> To: rpg400-l@midrange.com
> Subject: RE: data structure has no valid subfields
>
>
> Joe wrote:
>
> >One of the things I found when I was writing PSC400 was
> >that subfile record formats act a little differently
> >than others.  With subfile record formats, even
> >output-only fields are returned in the input
> >buffer.  Odd?  Yes.  But that's how it works.
>
> <chuckle> I asked IBM this question on my very VERY first
> subfile program on
> S/38.  The answer I got was to read the Fine Manual.
> Basically, the idea
> behind this aberration is to allow one to read a bunch of DB
> records, WRITE
> them to a subfile and then READ/C them back out without
> having to go back to
> the DB to get the "output only" fields.
>
> For the archives:
>
> I am ashamed to admit that I don't have a single book on
> subfiles, so I
> don't know if any midrange authors point this out, but it is in fact
> documented in that Fine old Manual, the Application Display
> Programming
> guide, page 4-13 (Reading an active record) and 4-14 (Reading the next
> changed record) have the same wording, to wit:
>
> "The entire record, including response
>  indicators (defined at the file level
>  and on fields in a subfile record),
>  input, output, output/input, and hidden
>  fields, is passed to the program, the
>  relative record number is placed in the
>  data management feedback area, and the
>  record is reset to a not changed record."
>
>   --buck