Procedure scope answers one question: who may PERFORM whom? In Easytrieve the answer is strict—only code inside the same activity as the PROC definition. A module at the end of JOB PAYROLL is invisible to PERFORM in JOB BONUS even when both activities sit in one source member. Library fields are program-wide, but procedure labels are activity-local. This tutorial maps activity boundaries, duplicate label rules across activities, report PROC placement within JOB scope, SCREEN isolation, SORT BEFORE procs, and refactoring patterns when shared logic must cross activity lines. Scope errors compile as undefined procedure and frustrate beginners who assume global visibility like COBOL COPY sharing.
An activity is a major division of an Easytrieve program: JOB name, SORT name, SCREEN name, PROGRAM name. Each activity contains executable statements plus PROC modules defined at its tail (or embedded for SCREEN). The compiler associates each PROC label with exactly one activity context. PERFORM resolves labels only in the current activity during compilation of that activity's executable section. Cross-activity PERFORM is not supported—you duplicate logic, use macros for compile-time reuse, or CALL external programs for runtime sharing.
12345678910111213JOB INPUT FILE-A PERFORM PROCESS-A PROCESS-A. PROC COUNT-A = COUNT-A + 1 END-PROC JOB INPUT FILE-B PERFORM PROCESS-B PROCESS-B. PROC COUNT-B = COUNT-B + 1 END-PROC
PROCESS-A cannot be PERFORMed from the second JOB; PROCESS-B cannot be reached from the first. COUNT-A and COUNT-B fields in Library remain visible everywhere if defined globally, but labels are not linked across the JOB boundary.
Beginners conflate procedure scope with variable scope. Easytrieve PROC modules do not create private variable namespaces like block scope in C. Fields defined in Library, FILE layouts, and working storage are visible in all activities unless your design uses separate files or deliberate naming conventions. PROC scope limits PERFORM label resolution only. Two activities may read and write the same GRAND-TOTAL field while maintaining separate CALC. PROC modules that each add to GRAND-TOTAL—coordinate concurrency if both activities run in one execution path.
| Item | Scope behavior |
|---|---|
| PROC label for PERFORM | Activity-local only |
| Library DEFINE fields | Program-wide unless redefined per rules |
| FILE record buffers | Visible per FILE definition across activities using that FILE |
| Report special-name PROC | Tied to REPORT within same JOB activity |
| MACRO expanded code | Compile-time copy into each use site |
Reusing CALC-TAX. PROC in two JOB activities is legal: each JOB owns its copy. Maintenance must update both when tax rules change unless you convert shared lines to a stored MACRO invoked in each activity. Some teams suffix labels CALC-TAX-A and CALC-TAX-B to force visual distinction in PERFORM lists even when logic is identical. Duplicate labels within one activity remain illegal—the compiler rejects two PROCESS-A. PROC definitions in the same JOB.
REPORT subactivities live inside a JOB activity. Report PROCs immediately follow their REPORT and share that JOB's procedure namespace with user job PROCs like START and CALC-TOTAL. BEFORE-LINE in REPORT DETAIL may PERFORM CALC-TOTAL defined among job PROCs above the REPORT block. Report PROCs from REPORT SUMMARY are not visible to REPORT DETAIL—each REPORT carries its own hook set. Multiple REPORTs mean multiple BEFORE-LINE modules with the same special name but different source positions tied to each REPORT.
SCREEN activities define INITIATION, BEFORE-SCREEN, and related PROCs inside the SCREEN block. JOB PERFORM cannot reach them. Online programs that also batch may duplicate validation PROC logic or extract shared validation to CALLed COBOL. SORT activities name BEFORE prescreen PROCs on the SORT statement; that label opens with PROC after the SORT activity header. JOB following SORT in program order is a separate activity—prescreen PROC cannot PERFORM job modules from a later JOB unless you restructure so both share one activity, which is usually impossible for SORT versus JOB roles.
When identical statement blocks must appear in two activities, a MACRO with parameters expands into each site at compile time. Runtime PERFORM linkage does not cross scope; macro expansion does not need PERFORM.
Tax calculation in COBOL called from PROC inside each activity shares one load module. Prepare USING fields before CALL identically in each duplicated thin PROC wrapper.
Small divergent activities may tolerate two similar PROC copies when merge cost exceeds benefit. Document both in change control when business rules update.
Each classroom has its own box of name tags for helper jobs. You can only pick a name tag from the box in your classroom. If two classrooms both have a tag called line-leader, they are different kids because the boxes are separate. Everyone in the school can still use the same hallway clock—that is like shared fields—but the name tags for helpers stay in each room's box.
1. A PROC defined in JOB PAYROLL can be PERFORMed from:
2. Two JOB activities may each define CALC-TAX. PROC because:
3. Report PROCs must appear:
4. Library DEFINE fields inside a PROC are visible:
5. PERFORM from JOB A to PROC in JOB B fails because: