|
What is happening is that the first SETLL against the first format FMT1
quickly found a record matching the format.
The subsequent SETLL is doing a position-file-cursor on the index of the
logical,
But this SETLL is actually doing a READE of the index until it finds a
format that matches the format that you requested (the format FMT2).
So even though it is a SETLL, it is reading and reading and reading,
throwing away the records that do not match the requested format until
it finds the requested format. I'll bet if we could see under the
covers that you are re-reading the records you just read in FMT1.
An alternative would be to do a READ LOGICAL, and using the RPG buffer
to test the format name, but obviously the SETLL FMT2 it is slightly
quicker since it is further down in the database level. If you choose
to re-write the program to READ LOGICAL without specifying a format but
instead taking whatever format is handed to you, you could then do a
Select to check the FMT just read, and I'll bet that you see that you
are already positioned to where you need after doing all the reads of
FMT1 ...... FMT1, FMT1, FMT1, FMT2, FMT2, FMT2, FMT3, FMT3, FMT3, FMT3
....
A CPYF *PRINT or DBU may show you the actual sequence of formats.
There are similar performance problems such as this when you use the DDS
keyword DYNSLT.
We needed to SETLL on each record format, because we needed to checkdifferent things
between different BOM files if we would find a record.
As an Amazon Associate we earn from qualifying purchases.
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.