Re: EOFDLY not working with full procedural file, only primary -- RPG400-L

A further note on this issue:

In the below code, if I leave the F-spec as keyed, but change

setll (*loval) ORDERH1;

to

setll *start ORDERH1;

it pays attention to the EOFDLY.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx

/
On 5/3/2022 3:18 PM, Peter Dow wrote:

This is on a v7r3 machine.

I'm using an OVRDBF with EOFDLY(9) on a logical file that has select/omit criteria.

IBM says

"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."

(from https://www.ibm.com/docs/en/i/7.3?topic=rdr-waiting-more-records-when-end-file-is-reached)

The ORDERH1 file is keyed by order#, and selects only unprocessed records, indicated by a flag set to 'R'. In order to handle the situation where an order might be added that has a lower number than an already processed record, I put the SETLL before the READ. When there are no records in ORDERH1, the program completely ignores the EOFDLY, and ends immediately. If I remove the SETLL, it waits on the READ for the expected 9 seconds.

Here's the code:

ORDERH (PF)
A          R ORDERHR
A            POORDN        16
A            INTSTATUS      1

ORDERH1 (LF)
A          R ORDERHR                   PFILE(ORDERH)
A          K POORDN
A          S INTSTATUS                 COMP(EQ 'R')

h option(*nodebugio: *srcstmt)
h dftactgrp(*no) actgrp(*caller)

FORDERH1   UF   E           K DISK    USROPN

IORDERHR

   open ORDERH1;

   dou %shtdn
       OR %eof(ORDERH1);

      setll (*loval) ORDERH1;

      read ORDERH1;

      if not %eof and not %shtdn;
         INTSTATUS = 'P';
         update ORDERHR %fields(INTSTATUS);
      endif;

   enddo;

   close ORDERH1;
   *inLR = *on;

If I remove the keyed access, and change the SETLL to SETLL *START ORDERH1, it pays attention to the EOFDLY.

In this situation, the aforementioned website 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."

So the questions I have are

1. Why does the SETLL cause the program to ignore the EOFDLY?

2. In the un-keyed version, IBM says it will retrieve only added records. If the file is re-using deleted records, will it find records added in the middle of the file?

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx /