× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

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