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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2022 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.