Easytrieve IF Control Flow

IF in the JOB Input Loop

1
2
3
4
5
6
7
8
9
10
JOB INPUT PAYROLL NAME UPDATE-RUN
  IF STATUS EQ 'D'
    GOTO JOB
  END-IF
  IF GROSS-PAY LT 0
    ADD 1 TO NEG-CNT
    WRITE ERRFILE
    GOTO JOB
  END-IF
  PRINT DETAIL-RPT

Each GET loads PAYROLL fields into the file buffer. First IF bypasses deleted rows entirely. Second IF tallies negative pay and writes an error extract without printing detail. GOTO JOB jumps to the next input iteration—skipping PRINT for bad rows. Both IF blocks need END-IF; GOTO does not replace END-IF.

ELSE-IF Chains for Status Bands

1
2
3
4
5
6
7
8
9
IF REGION EQ '10'
  MOVE 'EAST' TO WS-REGION-NAME
ELSE-IF REGION EQ '20'
  MOVE 'WEST' TO WS-REGION-NAME
ELSE-IF REGION EQ '30'
  MOVE 'CENTRAL' TO WS-REGION-NAME
ELSE
  MOVE 'UNKNOWN' TO WS-REGION-NAME
END-IF

Mutually exclusive region codes map to names in one flat structure. Only one branch runs. ELSE catches unlisted codes. Contrast with three separate IF statements—which could overwrite WS-REGION-NAME if multiple conditions were ever true. ELSE-IF implies prior conditions failed.

Nested IF for Dependent Conditions

Use nesting when inner logic applies only if outer is true: IF DEPT EQ 903 then IF GROSS GT LIMIT then FLAG-HIGH = Y. Outer false skips inner entirely. Each IF needs END-IF—two END-IF for two levels. Deep nesting beyond three levels signals time to extract a procedure or use ELSE-IF if conditions are actually parallel.

Condition Types in Batch Context

IF With SEARCH Decode

1
2
3
4
5
6
7
SEARCH DEPTTAB WITH DEPT GIVING WS-DEPT-NAME
IF DEPTTAB
  PRINT DETAIL-RPT
ELSE
  ADD 1 TO BAD-DEPT-CNT
  WRITE ERR-DEPT
END-IF

Valid department prints; invalid routes to error file with tally. IF DEPTTAB is presence test, not field comparison. Beginners who PRINT without IF risk stale GIVING from prior row.

IF in Procedures

BEFORE-LINE and screen procedures use IF for formatting guards—print bonus line only IF BONUS GT 0. Procedure IF follows same END-IF rules. Restricted contexts (sort BEFORE) forbid some statements inside IF bodies—verify prescreen allowed list before coding GET inside IF in sort procedures.

IF Versus DO — When to Choose

IF runs a block zero or one time per evaluation. DO repeats while or until condition changes. Walking an array uses DO with IF inside each pass. Do not wrap a single PRINT in DO—use IF when repetition is unnecessary.

Truth Flow After END-IF

Whichever branch executed—IF, ELSE-IF, or ELSE—control always continues at the first statement after END-IF unless GOTO, EXIT, or STOP redirected. Branches do not fall through into each other. Indentation in source is for humans; only END-IF delimits structure for the compiler.

Common IF Control Flow Mistakes

• Separate IF statements when ELSE-IF chain was intended—double execution risk.
• Missing END-IF in nested blocks.
• Testing EOF before first GET—EOF true at wrong time.
• PRINT on SEARCH without IF table presence test.
• GOTO without label that actually reaches next record logic.

Explain It Like I'm Five

IF is a question at each desk in a classroom. If the kid raised a hand, you give them a sticker. ELSE-IF is the next question only if the first answer was no: if not red, is it blue? ELSE is everyone left gets a plain pencil. END-IF is putting the sticker box away before the class moves to recess. GOTO JOB is telling one kid to skip show-and-tell and line up for lunch while the rest of the class keeps going.

Exercises

1. Rewrite three separate IF region tests as one ELSE-IF chain with ELSE.
2. Add NEG-CNT tally and ERRFILE write for invalid STATUS values.
3. Write nested IF: outer DEPT check, inner pay limit check—with two END-IF.
4. After SEARCH, branch PRINT versus ERROR with IF and IF NOT.
5. List statements forbidden inside sort BEFORE even when wrapped in IF.