|
Joel said: >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 would have hit on >that section. Having some vanishingly small experience writing manuals, I can only say that a reference manual can't be a good teacher AND a reference manual. Nor can a teaching manual be a good reference. The Application Display Programming guide is intended to be a teaching manual, and is meant to be read cover to cover. The debate on the quality of the education is outside the scope of this note, but suffice it to say that many fine people have made a good living teaching the concepts laid out there. >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? While not an expert, I would say that's been my experience. >Are there other situations like this one with >display files? None that immediately come to mind. >"Aberration" is a nice temperate term. My original "take" on this concept was a wild snort. I think I said "If I wanted those fields in the input buffer I would have made them 'both' fields and DSPATR(PR)." >I'm assuming this is a holdover from >the days when bandwidth constraints >were a lot more important. I never got a good answer, alas. --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.