Easytrieve Program Flow

Starting Point: PROGRAM or Implied Driver

An Easytrieve program contains at most one PROGRAM activity, and if present it must appear before all other activities. PROGRAM runs top-down until it ends, hits STOP, or encounters STOP EXECUTE or TRANSFER. When PROGRAM exists, it must EXECUTE JOB, SORT, or SCREEN activities—you choose when each runs. When PROGRAM is absent, Broadcom supplies an implied PROGRAM that executes JOB and SORT activities in source order until the first SCREEN.

JOB Activity Flow

JOB activities read one input record, process it, then repeat until EOF or STOP. Broadcom diagrams show RESET working storage, optional START PROC, automatic input retrieval, user IF and PERFORM logic, implied GOTO JOB at the bottom for the next record, and at EOF a FINISH PROC plus report wrap-up. Your coded statements sit in the middle of that skeleton. Forgetting implied iteration leads beginners to ask why statements run many times—it is by design for file processing.

1
2
3
4
5
6
JOB INPUT PERSNL NAME PAYJOB
   IF DEPT EQ SPACES
      GOTO JOB
   END-IF
   ADD GROSS TO WS-TOTAL
   PRINT PAY-RPT

Each PERSNL record triggers this block. GOTO JOB skips ADD and PRINT for blank department and immediately fetches the next record. Valid records accumulate WS-TOTAL and PRINT to PAY-RPT. After the last statement, implied GOTO JOB reads again until EOF triggers finish processing and report closing logic.

SORT Activity Flow

SORT activities read input, optionally run a BEFORE PROC with SELECT filtering, pass records to the sort engine, then write sorted output. Flow is not the same as JOB: there is a read loop, sort invocation, and output loop documented in Broadcom sort flow diagrams. Place SORT PROCs after the SORT activity statements. Downstream JOB activities often consume the sorted file produced here.

SCREEN Activity Flow

SCREEN flow cycles through RESET, optional INITIATION PROC, screen build and receive, BEFORE-SCREEN and AFTER-SCREEN PROCs, validation, and GOTO SCREEN to redisplay or proceed. TERMINATION PROC runs when the activity ends. Online flow is event-driven by terminal interaction rather than file EOF. GOTO SCREEN restarts the cycle including BEFORE-SCREEN; rules differ from GOTO JOB documented restrictions on WHERE SCREEN GOTO is allowed.

Control Statements That Alter Flow

Broadcom groups decision and branching tools: IF, CASE, DO WHILE, DO UNTIL, GOTO, PERFORM, EXECUTE, STOP, EXIT, REFRESH, and RESHOW. Each changes natural top-to-bottom order. PERFORM calls PROCs with return. EXECUTE switches activities. STOP ends execution. IF and DO evaluate conditional expressions including field relational, EOF file presence, and combined AND/OR logic with parentheses overriding default precedence.

Conditional Expression Precedence

In combined conditions, AND evaluates before OR unless parentheses group alternatives. Understanding precedence prevents logic bugs where OR binds wider than intended. Field series conditions compare one field against multiple values. File relational conditions like MATCHED support multi-file applications beyond beginner single-file reports.

Commit Points and Units of Work

Activities can define commit behavior with COMMIT parameters: ACTIVITY versus NOACTIVITY at termination, TERMINAL versus NOTERMINAL during screen I/O. Automatic commits mark logical units of work; abnormal termination triggers rollback of uncommitted updates on recoverable resources. COMMIT and ROLLBACK statements add manual control. Flow design must account for cursor closure and VSAM browse termination at commit points in database-backed programs.

Multi-Activity Batch Design

A single source member might define JOB EXTRACT, JOB REPORT, and SORT PREP. Implied PROGRAM runs them in order if no SCREEN intervenes. Explicit PROGRAM can EXECUTE only REPORT job when a control card demands it. Document flow between activities on a diagram pinned in the source library so operators know which JCL proc runs which mode.

Debugging Flow Problems

1. Confirm whether PROGRAM is explicit or implied.
2. Trace whether GOTO JOB skips records you expected to process.
3. Verify PERFORM returns to the correct caller after END-PROC.
4. Check STOP or STOP EXECUTE for premature termination.
5. Use DEBUG FLOW during test to see statement number sequence at abend.

Flow Anti-Patterns

• Mixing SCREEN auto-exec assumptions with batch-only testing.
• EXECUTE targets that never run because PROGRAM path omits them.
• Infinite-looking loops from GOTO label without progress toward EOF or STOP.
• PERFORM recursion accidentally created through nested calls.
• Ignoring EOF handling when custom FINISH PROC is required.

Explain It Like I'm Five

Program flow is the order you do things in a day. PROGRAM is the alarm clock that decides whether you eat breakfast before school or skip straight to homework. JOB is eating one bite at a time until the plate is empty, then washing dishes at the end. GOTO JOB is spitting out one bad bite and taking the next without finishing the rest on that fork. SCREEN is talking to a friend back-and-forth until you say goodbye. PERFORM is doing a chore list and coming back when the chore is done.

Exercises

1. Diagram implied PROGRAM flow for two JOB activities and one SORT with no SCREEN.
2. Explain what GOTO JOB does inside a JOB INPUT loop.
3. List five control statements that alter top-to-bottom flow.
4. Describe when explicit PROGRAM is required versus implied execution.
5. Write pseudo-flow for SCREEN from INITIATION through GOTO SCREEN.