There are two inherent problems with using the traditional indicator methods for controlling operations and branching:
It can lead to spaghetti code—unreadable programs that are harder to debug, modify, or enhance. For example, is indicator 38 used for the same thing in every program?
It isn't long before meaningful names for labels give way to less useful names. For example, what function is performed at the SKIP2 or SKIP3 tags?
To follow a more structured approach, the IF, DO, and SELECT-WHEN-OTHERWISE operation codes are used to produce more readable programs. Structured conditional logic using IF and SELECT-WHEN removes the need for any indicator-controlled logic, and most GOTO — TAG operations.
For example, the RPG code shown in Figures 7.3 and 7.4 should be written using modern operation codes. See Figures 7.5 and 7.6.
.....CSRn01Factor1+++++++OpCode(ex)Factor2+++++++Result++++++++Len++DcHiLoEq .....CSRn01..............OpCode(ex)Extended-factor2+++++++++++++++++++++++++++++ C IF FieldA = 'A' and FieldB = 'B' C ADD QTY TQTY C ADD QTY GQTY C MOVE '**' FLAG2 C MOVE '***' FLAG3 C endIf
.....CSRn01Factor1+++++++OpCode(ex)Factor2+++++++Result++++++++Len++DcHiLoEq C FieldA COMP 'A' 21 C FieldB COMP 'B' 22 C 21 CAN 22 DO C ADD QTY TQTY C ADD QTY GQTY C MOVE '**' FLAG2 C MOVE '***' FLAG3 C endDo
Figure 7.5 shows the preferred method of controlling program logic. Although the style in Figure 7.6 is more popular with some traditional RPG programmers, the method shown in Figure 7.5 is preferable because it:
Provides immediate identification of conditions that control the code.
Takes indicators out of the conditioning.
If performance is a concern, Figure 7.5 contains the most optimized code. In contrast, Figure 7.6 performs redundant comparisons:
The COMP operations that will set on the indicators.
Testing the indicator condition before entering the DO loop.