Easytrieve PROC — Opening a Procedure Module

PROC as Module Delimiter

Think of PROC as the left bracket of a function in modern languages. Everything between PROC and END-PROC belongs to one module. The compiler builds a symbol table entry for the label so PERFORM can branch there. If you omit PROC or misspell the label, PERFORM references fail at compile time with undefined procedure messages. If you omit END-PROC, the compiler may absorb later statements into the wrong module or report an unterminated procedure—see the END-PROC tutorial for recovery patterns.

1
2
3
4
5
6
7
8
VALIDATE-DEPT. PROC
  IF DEPT LT '01' OR DEPT GT '99'
     ERROR-FLAG = 'Y'
     ERROR-MSG  = 'INVALID DEPARTMENT'
  ELSE
     ERROR-FLAG = 'N'
  END-IF
END-PROC

VALIDATE-DEPT is the label PERFORM must reference. Statements inside the module can use IF, MOVE, GET, PRINT, nested PERFORM, and any executable statement allowed in that activity context. The module does not create a separate data area: fields defined in Library or working storage remain visible inside and after the PROC unless you deliberately isolate values in separate fields.

Label and PROC Syntax Variants

Broadcom documents proc-name. PROC on a single line as the common pattern. Some sites code the label alone on one line and PROC on the next; both forms declare the same module if delimiters follow release rules. Labels follow Easytrieve identifier rules: typically one to eight characters for user names unless your site extends limits in macro or library utilities. Special-name report and screen PROCs use reserved words documented in those chapters—do not invent alternate spellings expecting the report writer to find them.

User PROC Versus Special-Name PROC

User PROCs are modules you name for your own PERFORM calls—CALC-TAX, FORMAT-ADDR, SKIP-RECORD. Special-name PROCs are contract hooks between your source and Broadcom runtime events. Coding BEFORE-LINE. PROC after a REPORT block tells the report writer to run that module before each detail line formats. PERFORM BEFORE-LINE is wrong for that hook; the product dispatches it when the event occurs. Confusing the two families is a frequent beginner mistake: special names are not optional nicknames, they are event entry points with documented restrictions on statements allowed inside them.

User PROC characteristics

• You choose the label subject to identifier rules and uniqueness within the activity.
• Invocation is always PERFORM proc-name unless the logic is inlined without a module.
• May contain nested PERFORM to other user PROCs in the same activity.
• Shares all Library and activity working storage with the caller.

Special-name PROC characteristics

• Names are fixed by documentation—BEFORE-BREAK, AFTER-LINE, TERMINATION, and similar.
• Must appear immediately after the REPORT or SCREEN construct they serve.
• Some statements are invalid inside specific hooks—GOTO SCREEN in BEFORE-SCREEN, for example.
• Multiple REPORT activities in one JOB each carry their own report PROC set.

Placement Inside JOB Activities

Source order matters in Easytrieve batch programs. Executable JOB statements—GET implied by JOB INPUT, IF, MOVE, PRINT, WRITE—appear first. User job PROCs such as START, FINISH, or your custom modules follow that executable section. REPORT subactivities come next, each followed immediately by its report PROCs. Mixing report PROCs among job PROCs or placing user PROCs before executable logic triggers compile errors about invalid statement sequence. The skeleton below shows a valid ordering beginners can copy into new programs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
JOB INPUT EMPFILE
  IF STATUS EQ 'T'
     PERFORM TERMINATED-RTN
  END-IF
  PRINT PAY-RPT
 
START. PROC
  MOVE ZERO TO GRAND-TOTAL
END-PROC
 
TERMINATED-RTN. PROC
  TERM-COUNT = TERM-COUNT + 1
END-PROC
 
REPORT PAY-RPT
  TITLE 'PAYROLL REGISTER'
  LINE EMP-ID EMP-NAME GROSS-PAY
 
BEFORE-LINE. PROC
  ADD GROSS-PAY TO GRAND-TOTAL
END-PROC
 
TERMINATION. PROC
  * Grand total available for trailer logic if coded
END-PROC

PROC in PROGRAM, SORT, and SCREEN Activities

PROGRAM activities that replace or supplement batch JOB flows place user PROCs after executable PROGRAM statements using the same local-to-activity rule. SORT activities allow BEFORE prescreen PROCs named on the SORT statement; that procedure opens with the label from the BEFORE parameter followed by PROC and must SELECT records to include. SCREEN activities embed INITIATION, BEFORE-SCREEN, AFTER-SCREEN, and TERMINATION PROCs inside the SCREEN block rather than after it. Each activity is an island: a PROC defined at the end of JOB PAYROLL is invisible to PERFORM inside JOB BONUS—even in the same source member.

PROC and PERFORM Relationship

PROC declares; PERFORM invokes. You code PROC once per module and may PERFORM many times from IF branches, implied JOB loops, or nested PROCs. There is no parameter list on PROC itself—input and output use shared fields set before PERFORM and read after END-PROC returns. The procedure parameters tutorial explains that pattern in detail. PERFORM transfers control to the first statement after PROC; END-PROC returns to the statement following the PERFORM that entered the module. Nested calls stack in order: inner END-PROC completes inner PERFORM before outer END-PROC runs.

Naming and Readability Conventions

Sites often suffix user PROCs with -RTN, -PROC, or -LOGIC for clarity in PERFORM lists. Keep names descriptive enough that maintenance programmers recognize purpose without opening the module— CALC-STATE-TAX beats PROC017. Avoid duplicating the same label in one activity; the compiler rejects duplicate labels. Different activities may reuse the same label text because scope is activity-local—a pattern sometimes used for parallel JOB steps that share copybook-like logic structure but not runtime linkage.

Common PROC Opening Mistakes

• Coding executable PRINT or GET before the first PROC in an activity when those statements belong inside the module body after PROC.
• Using PERFORM on report special-name PROCs that the report writer should invoke automatically.
• Misspelling the label on PERFORM versus the PROC line—Easytrieve labels are not case-sensitive on z/OS but must match character for character.
• Placing report PROCs before the REPORT subactivity they belong to.
• Confusing MACRO expansion at compile time with PROC modules at runtime.
• Expecting formal parameters on the PROC line like COBOL USING—Easytrieve uses shared fields instead.

Testing PROC Modules

1. Compile after adding each new PROC to catch label and END-PROC pairing early.
2. Trace PERFORM paths with DISPLAY or audit fields to confirm which module ran for sample records.
3. Verify START and FINISH PROCs initialize and finalize counters before relying on TERMINATION report logic.
4. Confirm report PROCs fire by setting a test field in BEFORE-LINE and inspecting output sequence.
5. Review compile listing procedure map if your site listing includes cross-reference sections.

Explain It Like I'm Five

PROC is like writing a recipe card title at the top of a page. The title says this page is the chocolate-cake steps. When someone says make chocolate cake, they flip to that page—that is PERFORM. The recipe ends when you write the end on the card—that is END-PROC. Some recipe titles are ones you invent. Others are names the kitchen teacher already chose, like before-dinner-setup, and the teacher opens that card automatically at the right moment without you calling it.

Exercises

1. Write a user PROC VALIDATE-ZIP with IF logic and END-PROC; call it from JOB with PERFORM twice in different IF branches.
2. Sketch source order for one JOB with two REPORT activities and list where each BEFORE-LINE. PROC must appear.
3. Explain why PERFORM BEFORE-LINE is incorrect for a report detail hook.
4. Convert three duplicated MOVE blocks into one CALC-DEFAULTS. PROC module.
5. Compare Easytrieve PROC to JCL cataloged PROC in three sentences for a new teammate.