It had been a long time for me too. And I remembered it waiting for the
specified # of seconds, and waking up if a record was added before the
time elapsed, and if the time elapsed and no records were added, then it
would follow the EOF logic. But it actually just sleeps for the
specified amount of time, then wakes up and checks to see if any records
were added to the file, so using a large number of seconds is counter
productive if you want to process records as soon as possible after they
arrive.
The file is being loaded from a non-IBM i system, and I have to assume
it may be in random sequence.
When I read the IBM article I mentioned about it, it had 2 special
cases, both dealing with a keyed logical file with select/omit criteria.
"Also, special consideration should be taken when using end-of-file
delay on a file with a keyed sequence access path, opened so that the
keyed sequence access path is used. In this case, after end-of-file is
reached, the system retrieves only those records added to the file or
those records updated in the file that meet the specification of the
read operation using the keyed sequence access path."
It isn't clear whether it will read records that are added with a lower
key than were previously processed.
And for the non-key access, it says
"Special consideration should be taken when using end-of-file delay on a
logical file with select/omit specifications, opened so that the keyed
sequence access path is not used. In this case, after end-of-file is
reached, the system retrieves only those records added to a based-on
physical file that meet the select/omit specifications of the logical file."
And that isn't clear whether updating an existing record so that it
meets the select/omit criteria would then get processed. Or if it just
reads records added at the end of the file, or if it reads records added
in the middle of the file in the case where a file re-uses deleted records.
So to make sure I process all records, it seemed reasonable to use
SETLL. It's interesting that SETLL with a key makes it ignore the
EOFDLY, but with *START, it pays attention. But then there's the
question is it going back to the beginning of the file and processing
all records in arrival sequence and checking the select/omit criteria of
each record?
On 5/5/2022 1:31 PM, Sam_L wrote:
It's been a long, long time since I did anything with EOFDLY. As I
recall, the file just sat there indefinitely waiting for a new record
to be available. I don't recall a SETLL being needed. Maybe we used
the PF and didn't care about the sequence of the records being
processed? Does sequence matter to you?
Sam
midrange.com
