On 05-Nov-2013 16:47 -0800, Jerry C. Adams wrote:
<<SNIP>>
I do recall writing an RPG IV program defining a "flat file" as
"externally described" as opposed to using "program described"
I-specs. So these faux-fields, no matter how they are created,
have to be*real* fields to the DBMS. Also, if one runs DSPFFD
over a "flat file," these faux-fields are listed in the output.
The apparent existence of the fields is merely an *illusory* effect,
*in contradiction with* the concept [of *not externally described*
files]. I had been composing a long reply to try to explain that in
some detail, but I think the following will help make my point, in a
much more succinct manner.
Compare the output of the following two requests:
- DSPFFD QSYSPRT /* Note: zero fields, Externally Described = No */
- DSPFFD DDSprtf /* any non-system printer file created from DDS will
show the format and the fields; there can never be fewer than one field */
The *same effect* seen with the PRTF, legitimately, should be seen
for the DBF *if* the Database *FILE object had similarly and properly
reflected the concept of *not externally described* files. That is,
conceptually, any file that is *not* externally described, has *zero*
fields. Thus as a more realistic representation, DSPFFD should show
zero fields for a program described PF just as is seen for a PgmDesc PRTF.
Expounded... if interested:
However the actual implementation for DBFiles *deceptively* exposes
what are effectively one or more imaginary fields, regardless they
*should not* exist. That is almost surely a side effect of those
faux-fields being part of the /creation template/ of the file, and the
equivalent information being passed down to the LIC DB to create the
equivalently described Dataspace; i.e. the OS DB and the LIC DB are both
implemented with a requirement to have at least one /field/ to define
the record [format of the] data. Yet the conceptual definition of such
a file having zero fields, there was _no requirement_ to expose those
faux-fields to programs\users.
As it was, that effect of exposing the fields was *convenient* to
maximize consistency with other representations and design points. For
example there was a new requirement to reflect an apparent existence of
/keys/ which were previously only implemented as fields. The conundrum
of keys but no fields, was a requirement imposed by the representation
of System/36 files. Those S36 files only identified buffer positions
for its keys, not fields. So the DSPFD *could have* introduced a
totally unique and inconsistent way to present the keys, in a manner
other than revealing them as _apparent_ fields; i.e. they key
information for TYPE(*ACCPTH) could show the buffer positions that
define the key of a program described file, and show the fields that
define the key of an externally described file. Also having a field and
a record level format identifier, the database save\restore will utilize
that as a fast-path test to protect the data from overlay with other
files with the same record length, just as with externally described
files with different fields; an argument could easily be made against
that effect, such that no level-id, like the PRTF, might have been more
appropriate.
So while the fields are literally _implemented as_ *real fields* in
file creation and these [apparent] fields are manifest in field-list
retrieval, the ability to see the fields is merely a side effect of
attempts to make other intentions more [consistently] conspicuous.
Unfortunately, at the same time, their visibility causes confusion
whereby someone might /think/ there are fields, where conceptually there
are none. Note: The *DBXREF properly reflects zero-fields in the
file-of-columns [QADBIFLD] whenever DBXREL='N' in the file-of-files
[QADBXREF], even though the value for number of fields [DBXNFL] reflects
the number of faux-fields.
midrange.com
