Easytrieve PROC Statement

Statement Format

1
2
3
4
5
6
proc-name. PROC
  * executable statements
END-PROC
 
* Invocation:
PERFORM proc-name

Proc-name is a label identifying the module. Broadcom allows proc-name. PROC on one line or the label on one line and PROC on the next with proper delimiters. Every PROC must have matching END-PROC. PERFORM proc-name branches to the first statement after PROC; END-PROC returns to the statement following PERFORM.

User PROC Versus Report PROC

User PROCs are generic modules you design. Special-name PROCs use reserved labels documented in the report or screen chapters—coding BEFORE-LINE. PROC after a REPORT subactivity hooks detail line formatting; PERFORM is wrong for those hooks because the product calls them.

Placement in JOB Activities

Executable JOB statements—IF, MOVE, PRINT, GET—come first. Job PROCs such as START and FINISH follow executable logic. REPORT subactivities come after job PROCs. Report PROCs immediately follow the REPORT block they serve. Violating order produces compile errors that mention unexpected REPORT or PROC placement. A minimal skeleton:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
JOB INPUT PAYROLL
  IF DEPT EQ '99'
     PERFORM SKIP-RECORD
  END-IF
  PRINT DETAIL-RPT
 
START. PROC
  MOVE ZERO TO TOTAL-AMT
END-PROC
 
REPORT DETAIL-RPT
  TITLE 'PAYROLL LISTING'
  LINE EMP-NO EMP-NAME SALARY
 
BEFORE-LINE. PROC
  ADD SALARY TO TOTAL-AMT
END-PROC

PERFORM and Return Flow

PERFORM is the only way to invoke user PROCs. It is not a parameter pass like CALL USING—PROC shares Library fields and working storage with the caller. Changes to fields inside PROC remain visible after END-PROC unless you deliberately MOVE to local copies. Nested PERFORM is allowed: OUTER-PROC may PERFORM INNER-PROC. Recursion—OUTER performing INNER performing OUTER—is forbidden and yields unpredictable results or compile rejection.

END-PROC Rules

END-PROC must appear for every PROC. Omitting END-PROC leaves the compiler assuming later statements belong to the module, breaking REPORT placement and IF nesting. END-PROC is not END-IF; do not interchange them. Multiple PROCs in one activity each need their own END-PROC pair. EXIT inside PROC ends procedure flow early without executing remaining PROC statements— still requires eventual END-PROC at module level for structure.

PROC in PROGRAM and SCREEN Activities

PROGRAM activities place user PROCs after top-down executable statements. SCREEN activities place screen PROCs—INITIATION, BEFORE-SCREEN, AFTER-SCREEN, TERMINATION—in documented positions within the SCREEN block. BEFORE-SCREEN forbids GOTO SCREEN, REFRESH, and RESHOW; those restrictions apply to statements inside that PROC, not to PROC syntax itself.

PROC Versus CALL

Common PROC Mistakes

• PERFORM from a different activity than PROC definition.
• Missing END-PROC before REPORT subactivity.
• Recursion through nested PERFORM chains.
• PERFORM on special-name report PROC instead of letting writer invoke it.
• Report PROC coded before its REPORT block.
• Confusing PROC with PARSE or MACRO blocks.

Explain It Like I'm Five

PROC is a recipe card in a box. END-PROC is the bottom of the card. PERFORM means "go read that recipe now, then come back here when the card ends." You can put a recipe inside another recipe, but you cannot have recipe A call recipe B call recipe A again—that goes in circles. Special recipe names like BEFORE-LINE are ones the report machine reads automatically when it prints each line—you do not call those yourself.

Exercises

1. Write CALC-TAX PROC with END-PROC and two PERFORM call sites.
2. Sketch JOB source order: INPUT logic, START PROC, REPORT, BEFORE-LINE PROC.
3. Explain why recursion between PROCs is forbidden.
4. List three special-name report PROCs and when each runs.
5. Contrast PERFORM with CALL for a COBOL tax subroutine.