Easytrieve Procedures (PROC)

Why Use PROCs

Repetitive tasks—tax calculation, status validation, error messaging—appear in nearly every batch program. Copy-pasting logic creates drift: one branch gets fixed, another does not. PROCs centralize the task. PERFORM branches to the module; END-PROC returns to the next statement after PERFORM. Structured Easytrieve mirrors structured COBOL or modern functions, but uses Broadcom's PROC and PERFORM keywords.

User PROC Syntax

A user procedure starts with a label, the keyword PROC on the same or following line, one or more statements, and END-PROC. The label on PERFORM must match proc-name exactly. Broadcom allows proc-name. PROC on one line or proc-name followed by PROC on the next line with proper delimiters.

1
2
3
4
5
6
7
8
9
10
11
12
13
IF CODE EQ 1
   PERFORM CODE1-RTN
ELSE
   PERFORM CODE2-RTN
END-IF
 
CODE1-RTN. PROC
   ORDER-FLAG = 'NO'
END-PROC
 
CODE2-RTN. PROC
   ORDER-FLAG = 'YES'
END-PROC

When CODE equals 1, PERFORM CODE1-RTN runs the first procedure and sets ORDER-FLAG to NO. Otherwise CODE2-RTN sets YES. Control always returns to the statement after END-IF because END-PROC hands back to the caller PERFORM.

PERFORM Behavior

PERFORM is an unconditional branch to a procedure unless you wrap it in IF logic yourself. When Easytrieve hits PERFORM SPECIAL-BONUS, it jumps to that PROC, executes every statement until END-PROC, then continues with the next executable line after the PERFORM that called it. Nested PERFORM inside a PROC works the same way: inner END-PROC returns to the inner PERFORM's caller, then outer END-PROC returns to the original job logic.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
JOB INPUT PERSNL
   IF PAY-GROSS LT 300.99
      PERFORM SPECIAL-BONUS
   ELSE
      PERFORM STANDARD-BONUS
   END-IF
   PRINT MYREPORT
 
SPECIAL-BONUS. PROC
   XMAS-BONUS = PAY-GROSS * 1.20
END-PROC
 
STANDARD-BONUS. PROC
   XMAS-BONUS = PAY-GROSS * 1.05
END-PROC

PROC Types Compared

Placement Rules

Procedures are local to the activity in which they are coded. A PERFORM in JOB PAYROLL cannot reach a PROC defined at the end of a different JOB activity. Job PROCs sit after executable JOB statements and before REPORT subactivities. Report PROCs must immediately follow the REPORT they belong to—not mixed with job PROCs from the same activity. Violating placement produces compile errors about undefined procedures or invalid statement order.

Nesting Without Recursion

Broadcom explicitly warns that recursion is not permitted. Procedure A may PERFORM B, and B may PERFORM C, but neither B nor C may PERFORM A again directly or indirectly. Attempted recursion yields unpredictable results because the runtime does not maintain a safe call stack for infinite recursion. If you need repeated iteration, use JOB's implied loop, DO WHILE, or GOTO JOB—not PERFORM calling itself.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
IF DEPT EQ '911'
   PERFORM PROCA
END-IF
 
PROCA. PROC
   IF STATE EQ 'NY'
      PERFORM PROCB
   ELSE
      TAX = GROSS * 0.05
   END-IF
END-PROC
 
PROCB. PROC
   TAX = GROSS * 0.10
END-PROC

This nested pattern is valid: PROCA calls PROCB when STATE is NY. PROCB never calls PROCA back, so recursion rules are satisfied.

Report PROC Events

Report PROCs hook into the report writer lifecycle. REPORT-INPUT runs for each selected record before detail printing—you may filter further with SELECT inside the PROC. BEFORE-BREAK and AFTER-BREAK surround control break processing. BEFORE-LINE and AFTER-LINE bracket each detail line. ENDPAGE fires at page boundaries. TERMINATION runs at report end for grand totals or distribution messages. Each uses the same PROC / END-PROC envelope but is triggered by the product, not by your PERFORM statement.

Restrictions Inside PROCs

Most statements are allowed in user PROCs, but Broadcom limits certain I/O statements when PROCs run during SORT or REPORT processing. GET and PUT may be restricted in those contexts because the sort and report engines own record flow. Check your release documentation before placing file I/O inside report PROCs. When unsure, keep file reads in JOB logic and use report PROCs for formatting, masking, and last-chance SELECT tests.

Design Guidelines

• Name PROCs by purpose: VALIDATE-EMPNO, CALC-OVERTIME, not PROC1 and PROC2.
• Keep PROCs short enough to fit on one screen when possible.
• Prefer PERFORM over duplicated IF blocks; prefer IF over excessive GOTO.
• Document report PROC side effects when they alter fields used on LINE statements.
• Place all PROCs for an activity together so reviewers find modules quickly.

Common PROC Mistakes

1. Forgetting END-PROC, leaving the compiler unsure where the module ends.
2. PERFORM targeting a PROC in another activity.
3. Misspelling proc-name between PERFORM and the PROC label.
4. Placing report PROCs before REPORT or among job PROCs incorrectly.
5. Attempting recursive PERFORM for looping instead of JOB iteration or DO.

Explain It Like I'm Five

A PROC is a recipe card for one small cooking step, like how to frost a cupcake. PERFORM means read that card now, do what it says, then come back to the main recipe. END-PROC is the bottom of the card that tells you to return to the big cookbook. You can read a card that says open another card, but you cannot tell a card to open itself forever—that would never finish baking.

Exercises

1. Write two PROCs selected by IF and PERFORM for different bonus calculations.
2. Explain why PERFORM cannot call a PROC from another JOB activity.
3. List three report PROC names and when the report writer invokes each.
4. Convert a duplicated 10-line IF block into one PROC with two PERFORM calls.
5. Describe why recursion between PROC A and PROC B is forbidden.