Learn what the built-in functions %FOUND and %EOF are and how to use them to loop through files.

One of the most common business tasks is to loop through a file and process records. While many variations of code can be used for this particular task, over the years the community has tended toward a few basic techniques. This is a common occurrence in programming—so much so, in fact, that the idea has been codified into the concept of a design pattern. The book Design Patterns: Elements of Reusable Object-Oriented Software has sold over a half million copies worldwide. In this article, we'll review the common pattern of processing records in a file sequentially.

The Old Indicator Method

First off, when I say "sequentially" I don't necessarily mean the strict sense of reading through the file in relative record sequence; it could also (and usually does) mean in some sort of keyed order. For keyed record, that means using the SETLL and READE opcodes. In the days of indicators, we came up with a rather clever technique that allowed us to read through the file using just a few instructions. You'll probably recognize this code:

C  CUSTNO       CHAIN     ORDHDRL1                          90    

C  *IN90         DOWEQ   *OFF          

 *

C  OHSTAT       IFEQ     GOODVALUE

C               EXSR     PROCESS                                  

C               ENDIF

 *

C  CUSTNO       READE     ORDHDRL1                          90

C                ENDDO                                              

The loop is conditioned on an indicator—in this case, indicator 90. Both the CHAIN and the READE set that indicator on: the CHAIN if no record is found, and the READE if no more records match the key. If you've coded a database loop in RPG, you've almost certainly used this technique. The only tricky part is remembering where to put the indicator: for the CHAIN it's positions 71 and 72 while for the READE it's positions 74 and 75 (that's for RPG IV; the positions are different for RPG III, but the same concept applies).

Replacing Indicators with BIFs

When I teach people how to modernize their RPG code, one of the first goals is to remove all indicators. I do this through a number of techniques, the two primary ones being to use INDARA and INDDS to get rid of workstation indicators and using built-in functions (BIFs) to replace indicators. This article will focus specifically on replacing database I/O indicators with BIFs and explaining how that affects your code.

Converting the code example above to RPG /free involves not only changing the formatting of the code but also removing the indicators; RPG /free doesn't support either left-handed conditioning indicators or resulting indicators on operation codes. The RPG /free equivalent of the code looks like this:

setll CUSTNO ORDHDRL1;

reade CUSTNO ORDHDRL1;

dow not %eof(ORDHDRL1);                

  if (OHSTAT = goodValue);           

   exsr process;                    

  endif;                                

reade CUSTNO ORDHDRL1;

enddo;  

You can see that, except for the indicators, the code is essentially unchanged, although one significant difference may jump out at you: instead of the initial CHAIN, I instead use the SETLL/READE combination. That's because of the BIFs. CHAIN uses the %FOUND BIF to report its results: either it finds a record or it doesn't. READE, on the other hand, uses the %EOF BIF. It's awkward and potentially problematic to try to test both BIFs in the DOW loop. However, being savvy RPG programmers, we know that CHAIN is equivalent to SETLL/READE, so by replacing the CHAIN with the SETLL/READE pair, we can test the %EOF BIF and the do loop is complete.

A More Complete Pattern

While the code above solves the initial task of removing the indicators, the loop still has some structural issues, most of which arise from the READE being at the bottom of the loop. In this case, the code to skip a record is very simple: it's a single test. But in some cases, that code can become very complex. When that happens, the loop gets difficult because you have to make sure to have all of your test cases nested properly so that, at the end of all the tests, you drop down to the READE to get the next record. Another problem that gets me occasionally is that there are two physically separate READE statements, one before the loop and one at the end. Once in a while, I'll modify one of the READE statements and forget to modify the other one, and all kinds of programming hilarity will ensue!

In addition to avoiding those pitfalls, an all-purpose looping pattern will have several other features. A good pattern will:

1. 1.Handle a no-records condition.
2. 2.Support complex tests to skip records.
3. 3.Allow a maximum record count.

After coding several billion different database loops in my career, I've finally settled on the following loop. I use a variation on this code for nearly every database loop I write these days. In the past, I often reverted back to code like that shown in the second example, but nowadays if the processing logic is simple enough to code in that kind of loop, it's more often than not code that can be just as easily written with SQL.

The code below is the complete code pattern, with checks to handle no records, to leave the loop, and to skip records.

setll CUSTNO ORDHDRL1;                   

if not %equal(ORDHDRL1);                

  // No records                         

  leavesr;                               

endif;                                  

dou done;                               

  // Get next record, leave at EOF      

  reade CUSTNO ORDHDRL1;                

  if %eof(ORDHDRL1);                    

    leave;                              

  endif;                                

  // Check for conditions to skip record

  if (OHSTAT = badValue);           

    iter;                               

  endif;                                

  // Otherwise, process the order

  exsr processOrder;                    

  // Check for number of records

count += 1;

  if (count >= maxRecords);           

    leave;                               

  endif;                                

enddo;  

The very first thing you'll note is that I have a routine to check for no records. I execute a SETLL followed by checking the result of the %EQUAL BIF. %EQUAL returns true if one or more records are found and false if no records match the key. Note the LEAVESR; that implies that this particular load code is encapsulated in a subroutine. If it were in a procedure, I'd use a RETURN opcode. And in either case, I'd probably do some other logic to somehow indicate to the user that no records were found. This skeleton is just meant to show you that it's very easy to check for a no-record scenario.

The next thing you'll see is DOU DONE. The assumption here is that DONE is a named indicator that is always false. I wish there were a more elegant form of "do forever" in RPG (like DOW *ON), but this is what we have today. What this does is loop indefinitely until you explicitly leave the loop via a LEAVE instruction.

I immediately follow this with a READE. I test the results of the READE via the %EOF BIF; if it returns true, then I've run out of record, so I exit the loop using LEAVE. Otherwise, I continue on. At this point, I can execute as much conditioning logic as I need to test whether this record should be processed or skipped. Because the READE is at the top of the loop, any time I encounter a condition that will cause the record to be skipped, I simply execute the ITER opcode, which jumps to the top of the loop. Simple and easy.

Having passed the tests, I process the record. Again, this example uses EXSR rather than calling a procedure; BIFs are today's topic, not ILE. Finally, you'll notice that I increment the count, and if I've read enough records, I leave the loop.

Some variation of this pattern handles nearly all of my database looping requirements. Continuing the READE from the current position in the file takes a little more effort, but nothing all that difficult. Hopefully, this code will help you in your programming and even provide some inspiration for your own design patterns.