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 check
different things
between different BOM files if we would find a record.
midrange.com
