EXECUTE is a statement keyword that transfers control from a PROGRAM or SCREEN activity to another named activity—typically a JOB for batch reporting, a SORT for ordering input, or another SCREEN for stacked online windows. Before Easytrieve 11.6 function mode, some shops used EXECUTE as a harmless field name for a one-character run mode flag. Migration now reserves the token, so those programs fail compile until renamed. Understanding EXECUTE is essential for multi-activity programs: a PROGRAM wrapper that routes daily versus weekly jobs, or an online inquiry screen that launches an extract JOB after approval. This page covers statement format, nesting and recursion limits, stacked SCREEN behavior, contrast with PERFORM and CALL, STOP EXECUTE, migration renames, and beginner-safe patterns.
The EXECUTE statement is an activity transfer mechanism. Where PERFORM runs a procedure within the same activity, EXECUTE runs a whole JOB, SORT, or SCREEN activity declared elsewhere in the source module. Purpose: structure large systems as multiple activities without duplicating Library definitions, route processing based on parms or screen input, and support online-to-batch handoff. The PROGRAM statement in 11.6 enhances this model by letting one PROGRAM super-activity orchestrate several JOB activities under one LE run unit when ENVIRONMENT(COBOL) is specified.
1EXECUTE {job-name | sort-name | screen-name}
The operand is the NAME on a JOB, SORT, or SCREEN statement—not a procedure label and not a file name. Spelling must match the activity name exactly. EXECUTE has no inline parameter list; pass data through working storage fields, PARM fields, or files opened in both activities before the transfer.
| Context | EXECUTE allowed? | Note |
|---|---|---|
| PROGRAM activity | Yes | Primary orchestration pattern |
| SCREEN activity and its procedures | Yes | Includes AFTER-SCREEN approval flows |
| JOB activity | No | End JOB or use STOP; start next JOB implicitly |
| SORT activity | No | Chain with next SORT or STOP instead |
| REPORT subactivity | No | Use JOB logic to PRINT reports |
Broadcom states that after the invoked activity executes, control returns to the next executable statement following EXECUTE. If the JOB activity hits STOP, FINISH processing runs before return. Plan working storage lifetime: fields with RESET may clear between activities depending on attributes; document which flags must survive the round trip. RETURN-CODE may reflect the nested activity on MVS when the child sets it before return.
123456789101112131415PARM-FIELD W 5 A PROGRAM NAME SAMPLE-PROGRAM USING PARM-FIELD IF PARM-FIELD = 'DAILY' EXECUTE DAILY-JOB ELSE EXECUTE WEEKLY-JOB END-IF JOB NAME DAILY-JOB ... STOP JOB NAME WEEKLY-JOB ... STOP
The PROGRAM activity runs first on 11.6. PARM-FIELD might come from JCL PARM or an operator screen. Only one JOB executes per invocation; the other branch is skipped. Each JOB ends with STOP or implicitly when the next JOB would begin—here explicit STOP keeps the example clear for beginners.
EXECUTE from SCREEN can open another SCREEN activity—activity nesting. Each stacked window can EXIT back; when a stacked SCREEN terminates with EXIT, the product restores the prior full screen image from before the EXECUTE. EXIT from the primary screen does not restore a parent image because there is none. Design help screens and detail pop-ups as separate named SCREEN activities invoked with EXECUTE rather than duplicating hundreds of ROW statements in one map.
Recursion is forbidden: activity A may EXECUTE B, but B must not EXECUTE A. Broadcom warns recursion is not detected at compile time; runtime behavior is unpredictable. Code reviews should trace EXECUTE chains manually for cycles.
| Mechanism | Scope | Typical use |
|---|---|---|
| PERFORM | Procedure within same activity | Shared calculation or validation routine |
| EXECUTE | Whole JOB, SORT, or SCREEN activity | Route to batch job or stacked screen |
| CALL | External program | COBOL subroutine or vendor routine |
| GOTO | Label in same procedure/activity | Branch within screen or job logic |
STOP ends the current activity after optional FINISH procedure. STOP EXECUTE is stronger: it terminates the entire execute stream immediately without continuing to further activities. Use when fatal validation fails in a PROGRAM router or when an operator cancels a chained online-batch sequence. Do not confuse with EXIT from SCREEN, which returns from a nested screen to its caller when stacking is in play.
EXECUTE appears on the 11.6 New Reserved Words list. Legacy DEFINE EXECUTE W 1 A flags are common in pre-migration code. Rename to WS-RUN-MODE, FL-EXEC-FLAG, or PARM-EXECUTE-YN with a prefix that cannot collide with statement vocabulary. Scan PROCEDURE DIVISION–style comment text separately—only actual DEFINE and FILE names matter to the compiler. Retest PROGRAM wrappers after rename because IF EXECUTE = 'Y' becomes a syntax error, not a field test.
AFTER-SCREEN may validate approval, MOVE operator ID and date into audit fields, then EXECUTE NIGHTLY-EXTRACT-JOB. Operators need a message that batch work was submitted—do not block the terminal for the entire JOB unless your site architecture requires synchronous batch under TSO. JCL for EXECUTE targets must be available at runtime per installation standards. Coordinate with operations on transaction IDs when CICS is involved.
EXECUTE is telling the Easytrieve robot to pause this chore and go do a different named chore—like switching from homework to setting the table when Mom calls. When the other chore finishes, you come back to the next line of what you were doing. You cannot use the word EXECUTE as a label on your toy box anymore because it is the robot's command word. And you cannot ask chore A to start chore B if chore B tries to start chore A again—that makes the robot dizzy.
1. EXECUTE transfers control to:
2. EXECUTE is invalid inside:
3. Activity nesting allows:
4. After EXECUTE completes, control:
5. Legacy field named EXECUTE on 11.6: