× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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?


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.