On 01-Dec-2015 08:19 -0600, robwrote:
Your last paragraph is a huge thing.
The missing context, i.e. the missing paragraph [automatically cut
because of an End-Of-Signature marker], was an implication of the
importance of coding programs using Logical Independence, whereby a
program can [and IMO should] refer to a Logical File (LF) with named
columns instead of referring to a Physical File (PF) to gain
/independence/ from typical Record Format (RCDFMT) changes to the PF.
I'm not a big fan of each program having their own logical as the
access path overhead could get huge
One LF can serve many programs, and still there would be logical
independence; i.e. the programs do not refer to the physical layout.
Besides, the Access Path (ACCPTH) overhead does not change for the
effects of Logical Independence alone; keyed access path sharing remains
typical across multiple files [thus minimizing overhead]. If a program
would use a new LF solely for the different keyed ACCPTH, then that
would have been done irrespective of Logical Independence, and
unfortunately, likely often would have been effected *without* logical
independence, because only the K-specs would have been coded in the DDS
rather than the actual field names being included in the LF DDS.
but each logical that is created should explicitly select the columns
listed, even if it is all columns that are currently in the table.
That is a requirement for Logical Independence; i.e. the LF to which
the programs refer, must be one in which the field names were explicitly
included in the DDS [or ¿possible that a FORMAT specification may allow
reference to another LF for which the fields were explicitly included?].