Essentially, what's old is new again!

Those of us who used the RPG cycle and L1, L2, etc. for control-break processing remember how slick it was. Very few lines of code were needed, since most of the work was being done by the cycle code. As we proceeded into full procedural programming, we became aware that more code was needed to get the same result. Typically, we now needed save fields of control-break key fields, code to load the save fields, logic to see if the control-break key fields in the file changed from the save fields, and then more logic to handle the last group. Also, the save data needed to be updated in our control-break routine. This is pretty standard stuff that has been around for a long time.

Many years ago, I saw an alternative approach to this typical control-break logic. I don't remember where I saw it, but the idea stuck. After some "trial and error" time in programming, I derived a working solution (my memory wasn't all that good). There are some conditions that need to be met for this scheme to be usable: the file must have key fields, and we are processing the file in the order of the key fields. An example would be a file with keys of company number, customer number, and invoice number. A processing requirement is to sum invoices for a customer and produce a total. The partial key of company number and customer number are used for READE and SETGT operations.  

The element of coding in RPG IV that makes this new approach work is the way the READE operation works. A key list (inline or data structure) is supplied in the READE op code. If the key in the next record matches the key list parameters, then the record is successfully read. If the keys don't match, the file is said to be at end-of-file (eof), and the next record is not read. The "pre-read" function in READE is very much the same as the old cycle/L1 idea.

Some of the nice things to come out of this method are the following:

1. No save fields are needed.
2. No last group routine is needed.
3. You can code it all in free-format RPG IV.

Here is the detail program design (pseudo code) for this new approach:

While not at "end" (a user switch)

    Read the first record of a group (READ op code)

    While not at end of file (end of group really)

         Perform record processing

         Use the READE operation using the file's key fields to obtain the next record

    End-while

    Was any data read? (Check read count in File Info data structure > zero)

        Perform a control break routine — subroutine or subprocedure

   End-if

   Set the file pointer to next record after the current content of the file's control fields (SETGT)

    If not %found (this means true end of file, not just end of group)

        Set "end" switch to true

    End-if

End-while

That's it. The general idea of this routine is to have an outer loop based on a user named indicator I called "End." The Read at the top of the logic is a regular read. This reads the first record of each group. The logic after that processes the current record and then attempts to get the next record (READE). If the key in the file for the next record matches the key on the READE key list, the next record is read and the loop continues. If the key does not match, the end-of-file status is set to true (for READE, this is end-of-group). Upon return to the "do while," the expression is set to false and control moves outside the loop. The read count from 247 to 250 of the data file's information data structure is checked to see if any data was read. If true, the control break subroutine or subprocedure is performed. This check is done to avoid running the control-break routine if the file being processed has no data records.

Next, the file pointer is set to the next record after the last one used, using the SETGT operation and the same key data used on the previous READE. The built-in function %found is used to determine whether the true end of file has been reached. If it is, the return value for %found is true and the user switch "End" is set to *On. The logic of the outer loop takes program control to the top of the outer loop, where the "While" condition is now tested. If real end-of-file has not been reached, the loop is entered with the Read of the first record of the next group. If the "While" condition is false (the End switch is on), the program exits the outer loop, and additional program steps can be run. All groups have been processed, so there is no need for additional processing for the last group.

You may find this technique useful when coding your applications.