Re: just checking to see if record exists - SETLL on multi format logical versus individual files

Thanks John,
I am also seeing that the order of my primary file effects this
as well. There is a great difference when I process by item number (which is the order of the BOM files I am linking to), versus if
I process by Descending item Cost order, or Type of Item order. I would guess that difference is because of what you described in your alternative method.

-gerald




Voris, John wrote:

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.