Re: %EOF, %FOUND and the infamous Dow loop

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Joe,

You wrote:
>  Am I missing something here (more than usual)?

I'm afraid so.  The problem is with your test construct.

>I tried to use (%found or not %eof) along with the operation extenders,
>and it seems to always return true (putting me in an infinite loop
>reprocessing the last record over and over).

The fundamental mistake is the use of OR in a negative clause.  You should
be using AND.  Also, the operation extenders on I/O operations are only
for ERROR conditions (hence the E), the other BIFs are always available --
even if you specify indicators on the I/O operation.

The following code example works as you desire:

H OPTION(*NODEBUGIO)
FORDDTL    IF   E           K DISK

D detail        E DS                  EXTNAME(ORDDTL)

C     00202         CHAIN     ORDDTLR
C                   DOW       ( %FOUND(ORDDTL) AND
C                               NOT(%EOF(ORDDTL)) )
C                   EVAL      detail = detail
C     00202         READE     ORDDTLR
C                   ENDDO

C                   SETON                                        LR
C                   RETURN

If you are processing a single file you can simply use:
C                   DOW       (%FOUND AND not(%EOF))
but with multiple files, as is the case with most business applications,
you should specify the file name on the BIF.

%FOUND is set from the CHAIN and stays set until another CHAIN to that
file, %EOF is set by the READE thus the loop works as expected.

The only possible source of problems is if a previous I/O operation set
%EOF in which case we wouldn't enter the loop.  For example, add the
following line of code before the first CHAIN.
C     *HIVAL        READE     ORDDTLR
%EOF is now set and the DOW is not entered.  Ooops.  This problem will
also be apparent when entering the loop after the first group is
processed.  However, this problem can be corrected by repositioning using
*LOVAL before processing the next group of records.  I'm not advocating
that approach, merely pointing out that %FOUND and %EOF can be used
successfully.  Given the choice between an unneccesary double I/O to
remove %EOF and the double I/O of SETLL and READE suggested by Martin Rowe
I'd probably opt for SETLL/READE for no other reason than most RPG
programmers are familiar with it and they won't have to spend time
wondering why there is a
C     *LOVAL        SETLL     ORDDTLR
C                   READ      ORDDTLR
stuck in the code between groups of records.  I'd still prefer a way to do
this efficently with CHAIN because I've been advocating CHAIN in place of
the usual SETLL/READE combination for years.  That, of course, leads us
back to the construct:

C     00202         CHAIN     ORDDTLR
C                   IF        ( %FOUND(ORDDTL) )
C                   DOU       ( %EOF(ORDDTL) )
C                   EVAL      detail = detail
C     00202         READE     ORDDTLR
C                   ENDDO
C                   ENDIF

which is clean, obvious, and is probably what we should have been writing
all along except that we misused the I/O indicators by making them do
double duty (i.e., the same indicator was used for both EOF and NOT FOUND)
-- tsk, tsk.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------