This series focuses on program design and introduces you to ILE RPG operations that let you write well-designed programs by using a top-down, structured approach, including Selection and Iteration Operations. For Part One click here.

By Brian Meyers and Jim Buck

Editor's Note: This article is excerpted from chapter 5 of Programming in ILE RPG, Fifth Edition.

Loops and Early Exits

Sometimes you may want to skip the remaining instructions within a loop to begin the next iteration or cycle. In other cases, you may want to exit the loop completely before the repetition is terminated by the relational comparison. Two ILE RPG operations, Iter (Iterate) and Leave, give you these capabilities.

When the computer encounters an Iter operation, control skips past the remaining instructions in the loop and causes the next repetition to begin. Leave terminates the looping process completely and sends control to the statement immediately following the loop’s End statement. You can use either or both of these statements with all the iterative operations (Dow, Dou, and For)—but not with the selection operations (e.g., If, Select).

Assume, for example, you are processing a file of customer records and printing a report line for those customers whose balance due exceeds zero. If amount due equals zero, you simply want to cycle around and read the next record from the file. The following code illustrates a solution that uses Leave and Iter:

File Processing with Dow and Dou

Programmers often use the Dow and Dou operations in conjunction with repetitive processing of file records. The example in Chapter 2 used Dow to process the records in a file while there were records to read:

The first Read operation in this example—the one outside the loop, just before the Dow operation—is often called a priming read, because it primes the loop with data from the first record from the file (if there is one). After that record is processed, a second Read operation—inside the loop—is necessary to continue processing subsequent records.

With a few small changes to the code, the example can use Dou instead:

or

This version of the file loop does not require a priming read, because the first operation inside the loop reads a record from the file. Indeed, the structure needs only a single Read. But the loop does require an early exit from the loop if that lone Read operation encounters end-of- file. Without the conditional Leave operation at end-of-file, the last record is processed twice.

Which file loop structure is better? That’s a question best answered by a company’s

programming standards.

Top-Down Design

Up to now, this chapter has concentrated on structured design. A second design concept, top- down methodology, usually works together with a structured approach. Top-down design means developing your program solution starting with a broad outline and then successively dividing the big pieces into smaller and smaller units. This technique is sometimes called hierarchical decomposition.

Hierarchical decomposition is the method your English teacher recommended for writing research papers: work out an outline, starting with your main topics, then subdivide these into subtopics until you have decomposed to a level of sufficient detail to allow you to write the paper (or in programming terms, the individual instructions of your program).

Top-down design lets you handle problems of great complexity by permitting you to initially ignore the detailed requirements of processing. The top-down methodology works in tandem with modular program development, which advocates that you structure your

program into logical units, or modules. In top-down design, the first, or upper-level, modules primarily control flow to and from the lower-level modules you develop later.

Each module should be as independent of the others as possible, and the statements within a module should work together to perform a single function. Structural decomposition gives you a way to deal with complexity. When used with a modular approach, structural decomposition results in programs of functionally cohesive subroutines that are easier to maintain later.

ILE RPG supports three major constructs to handle top-down design and modular development:

• Subroutines
• Called programs (discussed in Chapter 13)
• Procedures (discussed in Chapter 14)

Defining and Using Subroutines

A subroutine is a named block of code, inside a program, with an identifiable beginning and end. It is a set of operations invoked as a unit by referring to the subroutine’s name but coded elsewhere within the program. After performing the subroutine, the program returns control to the statement immediately following the one that invoked the routine. A

subroutine is an organizational technique that isolates the details of a particular task and can be invoked repeatedly from other locations in the program.

You code a subroutine between Begsr (Begin subroutine) and Endsr (End subroutine) operations. The first line contains the Begsr operation and name of the subroutine. The lines of code constituting the executable portion of the subroutine follow. The last line of a subroutine contains the Endsr operation to signal the end of that subroutine. The following code shows the skeleton of a subroutine:

Subroutines are coded as the last processing entries, following all other processing in the main procedure. The order in which you list the subroutines does not matter, although many programmers prefer to specify them in alphabetical order for easy reference. A program can have an unlimited number of subroutines, but each must have a unique name, based on the same rules that apply to RPG variables.

To send control to a subroutine for execution, you use the Exsr (Execute subroutine)

operation. Enter the name of the subroutine to be performed, as follows:

The Exsr operation simply branches to the specified Begsr operation, executes the code in that subroutine, and then returns control back to the first line following the Exsr operation. The fact that control returns to a predictable location makes it possible to maintain tight control of program flow using Exsr.

Subroutines cannot contain other subroutines. They can execute other subroutines, but a subroutine should never execute itself. This latter coding technique, called recursion, is not permitted for subroutines.

You sometimes may want to skip the remaining instructions within a subroutine before the program gets to the Endsr operation. The Leavesr (Leave subroutine) gives you that opportunity. Leavesr sends control directly to the current subroutine’s Endsr operation. The following example uses Leavesr to quit the subroutine when it encounters end-of-file:

Most RPG programs use subroutines heavily because they let a programmer first code the main processing path in broad strokes, and then they relegate the details of a discreet task to a subroutine.

Using the *INZSR Subroutine

*Inzsr is a specially named subroutine that automatically executes whenever a program begins, before any other user-written code. Programmers commonly use the *Inzsr subroutine to provide initial setup processing for a program. A program can have only one subroutine named *Inzsr. It is like any other subroutine except that it is automatically

executed when the program starts. A program can also execute the *Inzsr subroutine by using the Exsr operation to reinitialize the program environment during processing. Here is an example of an *Inzsr subroutine:

In this case, the example provides initial values for program variables Default and Action. You can also accomplish this function by using the Inz keyword on the declarations for those variables. Typically, the *Inzsr subroutine is reserved for more complex initialization processing to perform before the main procedure portion of the program starts.

Next time: Control Break Logic and Navigating Legacy Code.  Buy Programming in ILE RPG, Fifth Edition at the MC Press Bookstore today!

Jim Buck's career in IT has spanned more than 35 years, primarily in the college education, manufacturing, and healthcare industries. Past president (13 years) of the Wisconsin Midrange Computer Professional Association, he has served on several teams developing IBM and COMMON certification tests. Jim has co-authored several IBM i textbooks with Bryan Meyers that are used by many companies and in colleges worldwide. Other accomplishments include: recipient of the 2007 IBM System i Innovation - Education Excellence Award, 2014 COMMON President's Award, and 2013/2016/2017 IBM Champion - Power Systems.

Jim is the president and founder of imPower Technologies, where he provides professional IBM i training and consulting services. He is active in the IBM i community, working to help companies train their employees in the latest IBM technologies and develop the next generation of IBM i professionals.

---

MC Press books written by Jim Buck available now on the MC Press Bookstore.

		Control Language Programming for IBM i Master the A-Z of CL, including features such as structured programming, file processing enhancements, and ILE. List Price $79.95 Now On Sale
		Mastering IBM i Get the must-have guide to the tools and concepts needed to work with today's IBM i. List Price $85.95 Now On Sale
		Programming in ILE RPG Get the definitive guide to the RPG programming language. List Price $95.95 Now On Sale
		Programming in RPG IV Understand the essentials of business programming using RPG IV. List Price $79.95 Now On Sale