Re: LVLCHK(*NO) - Looking for a Techdoc on why this is a bad idea (x-posted to RPG & MIDRANGE)

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?].

<<SNIP>>