Re: Indexing a Physical File

[CRPence <CRPbottle@xxxxxxxxx>]

  If the COBOL program declares and reads the LF via its index, 
then creating a different or another index [as /part of/ or 
otherwise] on the PF is atypically of any use.  The program will 
just use the index with those keys.  In this case, the LF being 
/accessed/ defines [the keys & ordering] and encapsulates the index. 
 If the encapsulation were by the PF or constraints [i.e. add index 
to PF], that matters little for data access via that file from the 
COBOL.  In either case, the index defines the order, and the COBOL 
retrieves the physical data accordingly; both cases directing first 
to an index, to choose which row to return to the program.  If the 
program were instead accessing the data via the SQL, then creating 
another index to provide statistics about the data and the ability 
to select very specific subset(s) of the data, might enable the SQL 
optimizer to access the data quicker.

  OK so now to clarify some above generalization for an index used 
for COBOL:
  - If the maximum key size is larger than required for the COBOL 
program, then a different & non-shared index would reduce the memory 
requirements for the index.
  - A larger pagesize for the index would be more efficient for 
reading the entire index; for read only access anyhow.
  - The physical data could be ordered to match the index to gain 
the greatest benefit from reading forward through the specific index 
as COBOL would; the command is RGZPFM with parameter KEYFILE() IIRC. 
 That would be run rarely due to expense, for example, so as to 
avoid spending 2X to save ~.4X once, versus more appropriately to 
save ~.35X more than six times.
  - The index and\or data can be brought into memory prior to 
processing, and with appropriate work management setup [sufficient 
memory for that and other work] can remain in memory [dedicated 
pool], if either most of or the entire index and\or data will be 
read by the program; the command is SETOBJACC, which can run just 
before the COBOL program.
  - A logical index could include select\omit logic to reduce the 
number of rows processed by the COBOL; i.e. if the program currently 
implements that logic.  The DYNSLT kwd effects moving the selection 
to the database just as without, but inclusion\exclusion tests are 
still required when the index is read; without DYNSLT, those tests 
are not required when the index is read.

Regards, Chuck

John Candidi wrote:
> Actually, there is a logical already built off the physical
> which is being accessed but I thought we could build an index
> on the physical and that might speed up the processing time
> for something reading that file. I could be way off base here
> because I just don't do a whole lot of this
>
> Booth Martin wrote:
> > Would it be easiest to create a keyed logical file over the 
> > physical?
> >
> > John Candidi wrote:
> > > How do you add an index to fields in a physical file which
> > > was defined in COBOL without recreating the file?