"Language Environment is the most important piece of software that COBOL programmers have never heard of. Every program they've ever written depends on it. Every abend they've ever seen was processed through it. And almost none of them know what it does." — Diane Okoye, Systems Architect, Pinnacle Health Insurance

Chapter Overview

In November 2022, Continental National Bank deployed a new COBOL subprogram — CNBVAL50 — as part of an account validation module. The program compiled cleanly. It passed unit testing. It passed integration testing. It was promoted to production on Sunday evening.

Monday morning, at 08:14 AM, the first CICS transaction that called CNBVAL50 abended with a U4038 — a Language Environment abend. The second transaction abended. The third. Within ninety seconds, forty-three transactions had failed and the CICS AOR entered a state of cascading failures.

The U4038 reason code pointed to an LE enclave initialization failure. The CEEDUMP showed that CNBVAL50 was compiled with Enterprise COBOL V4.2 — a version of the compiler that produced code compatible with an older version of LE. The CICS region was running LE at the z/OS 2.5 level. The runtime library mismatch caused LE initialization to fail on every invocation.

Kwame Mensah diagnosed it in four minutes by reading the CEEDUMP. The fix: recompile CNBVAL50 with the current Enterprise COBOL compiler. Total production impact: seven minutes. But the seven minutes were entirely preventable — if the deployment process had included an LE compatibility check.

"The CEEDUMP told us everything," Kwame said afterward. "The problem was that nobody on the team knew how to read it."

This chapter teaches you to read it.

What you will learn in this chapter:

1. What Language Environment is and why it exists — the layer between z/OS and your COBOL code
2. The complete LE initialization sequence from program load to your first PROCEDURE DIVISION statement
3. Enclaves and threads — the LE execution model that governs how subprograms behave in batch and CICS
4. The runtime options that control every aspect of your program's behavior, from storage management to error handling
5. How LE's condition handling model processes program failures — and how to configure it for production
6. How to read CEEDUMP output — the single most important production diagnostic skill for COBOL architects
7. LE tuning strategies for batch and CICS production environments

Learning Path Annotations:

• 🏃 Fast Track: If you're already familiar with LE runtime options, skip to Sections 3.5 and 3.6 (condition handling and CEEDUMP analysis). These are the skills that separate architects from programmers in production troubleshooting.
• 🔬 Deep Dive: Read Section 3.2 (initialization sequence) carefully even if it feels low-level. Understanding the initialization sequence explains why certain abends occur and why runtime option conflicts manifest the way they do.

Spaced Review — Chapter 1 and 2 Connections:

🔗 In Chapter 1, you learned that Language Environment initializes before your first line of COBOL executes and terminates after your last line completes. In Chapter 2, you learned that LE manages the heap, stack, and working storage allocation within the address space's virtual storage. This chapter explains how LE does both — the initialization sequence that sets up the storage model, and the condition handling that manages failures.

🔗 From Chapter 2: The S80A abend at CNB was caused by working storage exceeding the below-bar limit. LE was the component that issued the GETMAIN request that failed. Understanding LE's role in storage allocation (Section 3.4) explains why the RPTSTG report shows the data it does, and why LE runtime options like HEAP and STACK directly control the storage behavior you sized in Chapter 2.

3.1 Why Language Environment Matters — The Layer You Never Think About (Until It Fails)

Every COBOL program you've ever written relies on Language Environment. When you code a DISPLAY statement, LE handles the I/O. When you CALL a subprogram, LE manages the linkage. When your program abends, LE intercepts the hardware interrupt and decides whether to produce a dump, retry the operation, or percolate the error to a higher level. When your program terminates normally, LE runs cleanup routines — closing LE-managed resources, freeing storage, flushing buffers — before control returns to the operating system.

And yet, in twenty-five years of mainframe work, Kwame Mensah estimates that fewer than 10% of COBOL programmers have ever looked at an LE runtime option, and fewer than 2% can read a CEEDUMP.

What LE Provides

Language Environment is a common runtime environment for multiple high-level languages on z/OS: COBOL, PL/I, C/C++, and Fortran. Before LE (pre-1990s), each language had its own incompatible runtime library. COBOL programs couldn't reliably call PL/I programs. Error handling was inconsistent. Storage management was fragmented.

LE unified all of this into a single architecture:

LE Is Not Optional

You might think LE is a convenience layer — something you could skip if you wrote "bare metal" COBOL. You cannot. Enterprise COBOL generates code that requires LE. The compiled COBOL program contains calls to LE routines for:

• Working storage initialization
• File I/O (through LE's interface to z/OS access methods)
• PERFORM logic (LE manages the PERFORM stack in some scenarios)
• STRING, UNSTRING, INSPECT operations
• Decimal arithmetic overflow handling
• Program termination (STOP RUN and GOBACK)

Without LE, your compiled COBOL program is a collection of machine instructions that will immediately abend because the routines it calls don't exist.

💡 Intuition: Think of LE as the stage crew for a theater production. The actors (your COBOL program) perform the visible work. But before the curtain rises, the stage crew sets up the scenery (initialization), manages the lights and sound (runtime services), handles emergencies (condition handling), and strikes the set when the show ends (termination). The audience (users) never sees the crew, but without them, the show doesn't happen. An architect must understand both the actors and the crew.

3.2 LE Initialization: From Program Load to PROCEDURE DIVISION

When Rob Calloway's scheduler submits a batch job that runs a COBOL program, here's what happens between the z/OS program loader finishing its work and your first COBOL PROCEDURE DIVISION statement executing:

The Full Initialization Sequence

z/OS Program Loader
│
├── 1. Load module loaded into user region (from STEPLIB/JOBLIB/linklist)
│      Module contains: COBOL object code + LE stub code
│
├── 2. Control transfers to the LE stub (CEEMAIN/CEESTART)
│      This is the ENTRY POINT of the load module
│      ┌─────────────────────────────────────────────────┐
│      │  CEEMAIN — LE Main Entry Point                   │
│      │                                                   │
│      │  a. Establish the LE environment                  │
│      │     - Locate LE runtime library (SCEERUN/SCEELKED)│
│      │     - Verify LE version compatibility             │
│      │     - If mismatch → U4038 abend (the CNB incident)│
│      │                                                   │
│      │  b. Process runtime options                       │
│      │     Priority: CEEUOPT → PARM → installation      │
│      │     defaults (CEEDOPT in CEEUOPT)                 │
│      │                                                   │
│      │  c. Create the ENCLAVE                            │
│      │     - Allocate the Enclave Data Area (EDA)        │
│      │     - Initialize enclave-level control blocks     │
│      │                                                   │
│      │  d. Create the initial THREAD                     │
│      │     - Allocate the Thread Data Area (TDA)         │
│      │     - Initialize thread-level control blocks      │
│      │                                                   │
│      │  e. Allocate initial HEAP segment                 │
│      │     - Size determined by HEAP runtime option      │
│      │     - Issues GETMAIN for below-bar segment        │
│      │     - If LP(64): also IARV64 for above-bar segment│
│      │                                                   │
│      │  f. Allocate initial STACK segment                │
│      │     - Size determined by STACK runtime option     │
│      │     - Stack frame for the main program created    │
│      │                                                   │
│      │  g. Allocate WORKING STORAGE                      │
│      │     - For non-reentrant batch: single block via   │
│      │       GETMAIN from user region                    │
│      │     - For reentrant/CICS: from heap/DSA           │
│      │                                                   │
│      │  h. Initialize WORKING STORAGE                    │
│      │     - VALUE clauses applied                       │
│      │     - STORAGE runtime option fill applied to      │
│      │       non-VALUE items                             │
│      │                                                   │
│      │  i. Set up CONDITION HANDLING                     │
│      │     - Register LE's condition handler with z/OS   │
│      │     - Establishes ESPIE/ESTAE environments        │
│      │     - TRAP(ON) enables; TRAP(OFF) disables        │
│      │                                                   │
│      │  j. Transfer control to COBOL PROCEDURE DIVISION  │
│      │     - Via CEEENTRY macro in compiled code         │
│      │     - Your first COBOL statement executes         │
│      └─────────────────────────────────────────────────┘
│
├── 3. COBOL PROCEDURE DIVISION executes
│      (Your program runs — CALLs, I/O, SQL, etc.)
│
├── 4. STOP RUN or GOBACK reached
│
└── 5. LE Termination (CEETERM)
       a. Run COBOL user-defined termination paragraphs
       b. Close LE-managed files
       c. Free heap segments (FREEMAIN/IARV64 DETACH)
       d. Free stack segments
       e. Free working storage
       f. Destroy thread and enclave
       g. Produce RPTSTG report (if RPTSTG(ON))
       h. Return to z/OS (return code from COBOL RETURN-CODE)

What Can Go Wrong During Initialization

Every step in the initialization sequence is a potential failure point. Here are the failures that Kwame's team has seen at CNB:

The most common of these — by far — is the U4038 LE compatibility failure. It happens every time someone promotes a load module compiled with an older compiler to a system running a newer LE. The fix is always recompilation.

⚠️ Common Pitfall: Some shops maintain load modules compiled years ago — "it works, don't touch it." These modules are time bombs. Every z/OS upgrade includes an LE upgrade. Eventually, the compatibility gap exceeds LE's tolerance, and the module fails with U4038 on the first invocation after the upgrade. CNB's policy: every production load module is recompiled annually with the current compiler, even if the source code hasn't changed. "Recompilation is insurance against LE incompatibility," Kwame says.

🔄 Retrieval Practice — Check Your Understanding: 1. What is the very first thing LE does when it receives control from the z/OS program loader? 2. In what order does LE process runtime options from multiple sources (CEEUOPT, PARM, installation defaults)? 3. What abend code indicates an LE version compatibility failure? 4. From Chapter 2: Which step in the initialization sequence issues the GETMAIN that can cause an S80A?

3.3 Enclaves and Threads — The LE Execution Model

The enclave and thread model is how LE organizes program execution. Every piece of COBOL code runs inside an enclave, on a thread. Understanding these constructs explains why subprogram behavior differs between batch and CICS, and why some CALL patterns cause storage leaks.

What Is an Enclave?

An enclave is LE's unit of program execution. It roughly corresponds to a "run unit" — a main program and all the subprograms it calls. In batch, there's typically one enclave per job step. In CICS, there's one enclave per task.

The enclave owns: - The runtime options (resolved at enclave creation from CEEUOPT, PARM, defaults) - The heap (all heap segments for this execution) - All open files managed by LE - The condition handling environment - The return code (RETURN-CODE special register)

When the enclave terminates, all of its resources are freed — heap, stack, files, everything. This is why a CANCELed subprogram's working storage is freed: LE manages subprogram storage within the enclave, and CANCEL tells LE to release it.

What Is a Thread?

A thread in LE terminology is a unit of execution within an enclave. In COBOL batch, there is almost always one thread per enclave. COBOL doesn't natively support multi-threading in the Java or POSIX sense — each COBOL program runs on a single LE thread.

The thread owns: - The stack (all stack frames for this call chain) - The current condition (if an error has occurred) - Thread-local storage

Enclave Behavior: Batch vs. CICS

This is where it gets critical:

BATCH:
┌───────────────────────────────────────────────────────┐
│  Job Step                                              │
│  ┌───────────────────────────────────────────────┐    │
│  │  Enclave (created at LE init, destroyed at     │    │
│  │           program termination)                  │    │
│  │                                                 │    │
│  │  Thread 1:                                      │    │
│  │  ┌─────────────────────────────────────────┐   │    │
│  │  │ Main Program (CNBGL300)                  │   │    │
│  │  │  └── CALL subprogram A                   │   │    │
│  │  │       └── CALL subprogram B              │   │    │
│  │  │  └── CALL subprogram C                   │   │    │
│  │  └─────────────────────────────────────────┘   │    │
│  │                                                 │    │
│  │  Heap: Working storage for A, B, C (if reentrant)│  │
│  │  Stack: Call frames for main → A → B → C        │  │
│  └───────────────────────────────────────────────┘    │
│                                                        │
│  One enclave for the entire job step.                  │
│  Enclave lives for minutes to hours.                   │
└───────────────────────────────────────────────────────┘

CICS:
┌───────────────────────────────────────────────────────┐
│  CICS Region (Address Space)                           │
│                                                        │
│  Task 1:                          Task 2:              │
│  ┌─────────────────────┐        ┌─────────────────┐   │
│  │ Enclave 1            │        │ Enclave 2        │   │
│  │  Thread 1:           │        │  Thread 1:       │   │
│  │  PROG-A → SUB-X     │        │  PROG-A → SUB-Y │   │
│  │  (own WS copies)    │        │  (own WS copies) │   │
│  │  Heap: SUB-X WS     │        │  Heap: SUB-Y WS  │   │
│  │  Stack: PROG-A→X    │        │  Stack: PROG-A→Y  │   │
│  └─────────────────────┘        └─────────────────┘   │
│                                                        │
│  Task 3:                          Task 4:              │
│  ┌─────────────────────┐        ┌─────────────────┐   │
│  │ Enclave 3            │        │ Enclave 4        │   │
│  │  Thread 1:           │        │  Thread 1:       │   │
│  │  PROG-B → SUB-Z     │        │  PROG-A → SUB-X │   │
│  └─────────────────────┘        └─────────────────┘   │
│                                                        │
│  Each CICS task = one enclave.                         │
│  Enclaves live for milliseconds (transaction duration).│
│  Hundreds of enclaves may exist simultaneously.        │
└───────────────────────────────────────────────────────┘

Subprogram Working Storage: The CALL/CANCEL Lifecycle

Understanding enclaves explains one of the most common storage problems in COBOL — the storage "leak" caused by dynamic CALL without CANCEL.

Static CALL: The subprogram is linked with the main program. Its working storage is part of the main program's storage. No separate heap allocation occurs. No lifecycle issue.

Dynamic CALL (first invocation): LE allocates the subprogram's working storage from the heap. VALUE clauses are applied. The subprogram executes and returns via GOBACK.

Dynamic CALL (subsequent invocations, no CANCEL): The subprogram's working storage persists. It was not freed. LE returns to the same working storage copy, with all values from the previous invocation intact. This is the "IS INITIAL" vs. default behavior distinction — default behavior preserves working storage across calls.

CANCEL: LE frees the subprogram's working storage from the heap. The next CALL to the canceled subprogram allocates fresh working storage and reinitializes VALUE clauses.

The storage leak pattern:

      * PROBLEMATIC PATTERN — storage leak in long-running batch
       PERFORM VARYING WS-IDX FROM 1 BY 1
           UNTIL WS-IDX > 10000000
           CALL 'VALIDATE' USING WS-RECORD(WS-IDX)
      *    No CANCEL — working storage for VALIDATE persists
      *    But if VALIDATE is loaded fresh each iteration
      *    (e.g., via COBOL dynamic loader), each CALL may
      *    allocate a NEW copy of working storage on the heap.
       END-PERFORM

If VALIDATE is loaded and released on each call cycle (which can happen with certain CALL/CANCEL patterns or with reentrant programs in specific environments), each invocation allocates heap storage that accumulates. Over 10 million iterations, even a small working storage section multiplied by millions of invocations consumes gigabytes.

✅ Best Practice: For long-running batch programs that call subprograms in loops: either use static CALL (no heap allocation per call), or call the subprogram once before the loop and CANCEL once after the loop — never CANCEL inside the loop. "CANCEL inside a tight loop is an anti-pattern," says Lisa Tran. "It forces LE to allocate and free storage millions of times. The overhead alone can double your elapsed time."

Preinitialized Environments: LE in CICS

CICS uses preinitialized LE environments. Instead of LE performing full initialization for every transaction, CICS pregenerates the LE environment at region startup. Each task's enclave is created from this preinitialized template — much faster than full initialization.

This is why LE runtime options in CICS are configured differently than in batch:

• In batch: Runtime options come from CEEUOPT (linked), PARM (JCL), or installation defaults.
• In CICS: Runtime options come from the CICS system initialization parameters and the CICS-LE interface. You cannot pass LE options via PARM in CICS — there is no PARM.

CICS-specific LE configuration is done through: - CICS SIT (System Initialization Table): Parameters like AUTODST=YES control LE's storage tracking for CICS tasks. - CEEDOPT/CEECOPT: Installation-wide defaults for batch (CEEDOPT) and CICS (CEECOPT). These are assembled and linked into the LE runtime library. - CEEUOPT for CICS programs: Can be linked with individual CICS programs, but affects only the options not controlled by CICS.

⚠️ Common Pitfall: A developer tests a COBOL program in batch with PARM='/STORAGE(00,FE,00)' and it works perfectly. They deploy to CICS without understanding that PARM-based runtime options don't apply in CICS. The program behaves differently in CICS because the STORAGE option isn't set. Always configure CICS LE options through CEECOPT or the CICS SIT, not through PARM.

Enclave Termination: The Cleanup Guarantee

One of LE's most important behaviors is the cleanup guarantee at enclave termination. When an enclave ends — whether normally (STOP RUN, GOBACK from the main program) or abnormally (abend) — LE performs a comprehensive cleanup:

1. All heap segments are freed. Every GETMAIN that LE issued for this enclave's heap is paired with a FREEMAIN. This includes working storage for dynamically CALLed subprograms, STRING/UNSTRING work areas, and any storage obtained via CEEGTST.

2. All stack segments are freed. Stack frames for every call level, including LOCAL-STORAGE allocations, are released.

3. LE-managed files are closed. If a COBOL program opened files via OPEN and didn't close them before termination, LE closes them during cleanup. (This is a safety net, not best practice — always close your files explicitly.)

4. Condition handlers are deregistered. ESPIE and ESTAE exits registered during initialization are removed.

5. The RPTSTG report is produced (if RPTSTG(ON)). This happens during termination, which is why the report shows "available at termination" storage — LE is reporting from inside the cleanup process.

This cleanup guarantee is why an enclave is the "blast radius" for storage problems. A heap leak in one enclave cannot affect other enclaves — each enclave tracks its own heap segments, and termination frees them all. In CICS, this means a storage problem in one transaction's enclave cannot leak storage into other transactions' enclaves. The CICS region's DSA may be temporarily affected (until the enclave's task-level storage is freed), but the contamination is contained.

At CNB, Kwame tests this guarantee annually: "We have a test program that intentionally leaks heap storage — allocates without freeing. We run it repeatedly in CICS. After each transaction, we verify that ECDSA returns to its baseline. If it doesn't, something is wrong with LE cleanup, and we escalate to IBM. In seven years of testing, it has never failed."

LE Callable Services for COBOL Programs

While most COBOL programs interact with LE implicitly (through compiled code), architects occasionally need LE callable services directly:

The most commonly used in production COBOL are the date services (CEECBLDY, CEEDATE) and the heap services (CEEGTST, CEEFMDA). Date services are essential for programs that need to handle multiple date formats (Lilian, ISO, YYYYMMDD, Julian). Heap services are used when a program needs dynamic storage beyond what WORKING-STORAGE provides — for example, building variable-length output buffers or managing temporary work areas whose size depends on input data.

🔄 Retrieval Practice — Check Your Understanding: 1. What is the relationship between a CICS task and an LE enclave? 2. In batch, how many enclaves typically exist per job step? 3. What happens to a dynamically CALLed subprogram's working storage when you CANCEL it? 4. From Chapter 2: How does the enclave's heap allocation relate to the address space's virtual storage? Where in the address space diagram (Section 2.2) does the heap live?

3.4 LE Runtime Options — The Forty Switches That Control Your Program's Behavior

LE has approximately 40 runtime options, but a COBOL architect needs to know about 15-20 of them. The others are language-specific (PL/I, C) or obscure. This section covers every option that matters for production COBOL.

Runtime Option Priority

When multiple sources specify the same option, LE resolves conflicts using a strict priority:

Priority (highest to lowest):
1. CEEUOPT — assembler module linked with the COBOL program
2. PARM field — on the EXEC statement in JCL (batch only)
3. CEECOPT — CICS installation defaults (CICS only)
4. CEEDOPT — installation-wide defaults (batch)
5. LE internal defaults (hardcoded in LE)

Each option also has an override attribute: some options can be overridden by higher-priority sources; others are "non-overridable" when set in CEEUOPT. The RPTOPTS(ON) option produces a report showing exactly which source each option came from — invaluable for diagnosing option conflicts.

The Essential Runtime Options for COBOL Architects

Group 1: Storage Options (covered in Chapter 2, summarized here for completeness)

Group 2: Diagnostic Options

RPTOPTS in action:

LAST WHERE SET    OPTION
----- ---------   ------
CEEUOPT           HEAP(1048576,1048576,ANYWHERE,KEEP,67108864,33554432)
CEEDOPT           STACK(131072,131072,ANYWHERE,KEEP,524288,131072)
PARM              RPTSTG(ON)
CEEDOPT           STORAGE(NONE,NONE,NONE)
CEEUOPT           ALL31(ON)
CEEUOPT           TRAP(ON,SPIE)

This report tells you instantly: HEAP and TRAP were set by CEEUOPT (linked with the program — high priority). STACK and STORAGE came from CEEDOPT (installation defaults — low priority). RPTSTG came from the JCL PARM field. If STORAGE should be (00,FE,00) but the report shows (NONE,NONE,NONE), you know the installation default hasn't been updated — and CEEUOPT or PARM needs to set it.

Group 3: Error Handling Options

Group 4: Program Behavior Options

CEEUOPT: The Architect's Primary Configuration Tool

The CEEUOPT module is the highest-priority source for runtime options (in batch). It's an assembler source file that uses the CEEXOPT macro to specify options:

CNBOPT   CEEXOPT HEAP=(1048576,1048576,ANYWHERE,KEEP,               X
                       67108864,33554432),                           X
                 STACK=(524288,524288,ANYWHERE,KEEP,                 X
                        524288,131072),                              X
                 STORAGE=(00,FE,00),                                 X
                 RPTSTG=OFF,                                         X
                 ALL31=ON,                                           X
                 TRAP=(ON,SPIE),                                     X
                 ABTERMENC=ABEND,                                    X
                 CEEDUMP=ON,                                         X
                 TERMTHDACT=TRACE,                                   X
                 RPTOPTS=OFF
         END

This assembler source is assembled and linked with the COBOL load module:

//LKED    EXEC PGM=IEWL,PARM='RENT,LIST,XREF'
//SYSLIB   DD DSN=CEE.SCEELKED,DISP=SHR
//         DD DSN=CNB.PROD.OBJLIB,DISP=SHR
//SYSLMOD  DD DSN=CNB.PROD.LOADLIB(CNBGL300),DISP=SHR
//SYSLIN   DD DSN=CNB.PROD.OBJLIB(CNBGL300),DISP=SHR
//         DD DSN=CNB.PROD.OBJLIB(CNBOPT),DISP=SHR
//         DD *
  INCLUDE SYSLIB(CEEUOPT)
  ENTRY CNBGL300
  NAME CNBGL300(R)
/*

Why CEEUOPT over PARM? Because CEEUOPT is linked into the load module — it travels with the program. PARM is in the JCL — it can be changed by operators, forgotten during job copies, or omitted in emergency restarts. "CEEUOPT is controlled by architects. PARM is controlled by whoever touches the JCL last," says Kwame.

💡 Intuition: Think of CEEUOPT like a car's factory settings — programmed at the factory (compile/link time), specific to the model (this program), and always present regardless of who drives (operates) the car. PARM is like the driver adjusting the seat and mirrors — it overrides some settings, but only for this trip (this job run), and the next driver might change them back.

🧩 Productive Struggle: Before reading Section 3.5, consider this scenario: A COBOL program has TRAP(ON) in its CEEUOPT. The CICS region has TRAP(OFF) in its SIT parameters. The program is deployed to CICS. Which setting wins? What happens when the program encounters an S0C4? Try to reason through the priority model before reading the answer in Section 3.5.

3.5 Condition Handling — What Happens When Your Program Fails

LE's condition handling model is the most sophisticated (and most misunderstood) aspect of the runtime environment. It determines what happens between the moment your program encounters an error and the moment a CEEDUMP appears in your SYSOUT.

The Condition Handling Sequence

When your COBOL program encounters a hardware interrupt (S0C4, S0C7, S0C1) or a software error (LE-detected):

1. HARDWARE INTERRUPT
   │ (e.g., protection exception → S0C4)
   │
   ▼
2. z/OS INTERRUPT HANDLER
   │ Saves PSW, registers
   │ Checks for ESPIE/ESTAE exits
   │
   ▼
3. LE CONDITION HANDLER (if TRAP(ON))
   │ LE registered ESPIE/ESTAE during initialization (step 2i)
   │
   │ a. Build the CONDITION TOKEN
   │    - Severity (0-4): 0=info, 1=warning, 2=error, 3=severe, 4=critical
   │    - Message number (e.g., IGZ0006S for S0C4 in COBOL)
   │    - Facility ID (IGZ = COBOL, CEE = LE, IBM = system)
   │
   │ b. Check for USER-WRITTEN CONDITION HANDLERS
   │    - Registered via CEEHDLR callable service
   │    - Rare in COBOL; common in PL/I and C
   │
   │ c. Check for COBOL language-specific handling
   │    - ON SIZE ERROR → resume after arithmetic
   │    - AT END → resume after READ
   │    - INVALID KEY → resume after VSAM operation
   │    - IF these exist, LE resumes the program
   │
   │ d. If no handler claims the condition:
   │    LE checks ABTERMENC option
   │    - ABEND: Terminate with abend code, produce dumps
   │    - RETCODE: Set return code, terminate normally
   │
   ▼
4. TERMINATION PROCESSING
   │ a. CEEDUMP produced (if CEEDUMP(ON))
   │ b. LE traceback printed (if TERMTHDACT includes TRACE)
   │ c. Storage report printed (if RPTSTG(ON))
   │ d. Runtime option report printed (if RPTOPTS(ON))
   │ e. Enclave destroyed, storage freed
   │ f. Abend issued (if ABTERMENC=ABEND)
   │    → z/OS sees abend → SYSUDUMP/SYSABEND produced
   │
   ▼
5. z/OS JOB STEP TERMINATION
   Condition code set in JES2 job log

TRAP(ON) vs. TRAP(OFF): The Critical Switch

TRAP(ON) tells LE to register its condition handler (ESPIE and ESTAE exits) with z/OS during initialization. With TRAP(ON), LE intercepts hardware interrupts before z/OS produces a system dump. This means LE can produce a CEEDUMP, a traceback, and an RPTSTG report — all of which are far more useful for COBOL debugging than a raw system dump.

TRAP(OFF) tells LE to not register its condition handler. Hardware interrupts go directly to z/OS, which produces a system dump (SYSUDUMP/SYSABEND) but no CEEDUMP, no LE traceback, no storage report. You get raw hex dump instead of formatted COBOL diagnostics.

Always run with TRAP(ON) in production. The only legitimate reason for TRAP(OFF) is debugging a suspected LE condition handler bug — and that's a once-per-decade scenario.

The Severity Model

LE classifies every condition by severity:

The condition token — a 12-byte structure — carries the severity, facility ID, and message number. LE callable services like CEEGQDT (Get Condition Token) allow programs to inspect the condition programmatically, but this is rarely used in COBOL (more common in PL/I).

Condition Handling in CICS: Special Considerations

In CICS, LE's condition handling interacts with CICS's own error handling:

• EXEC CICS HANDLE ABEND registers a CICS-level abend handler. If a COBOL program abends, CICS's handler runs after LE's condition handling.
• CICS transaction abend codes (e.g., AICA, ASRA) are issued by CICS, not by LE. ASRA (S0C4 in a CICS program) means LE detected the S0C4 and percolated it to CICS, which then issued the ASRA transaction abend.
• CICS DUMP vs. CEEDUMP: A CICS transaction dump (produced by EXEC CICS DUMP or by CICS's abend handling) is different from a CEEDUMP. Both may be produced for the same abend. The CEEDUMP shows LE-level information (heap, stack, traceback); the CICS dump shows CICS-level information (EIB, comm areas, DSA usage).

At CNB, the CICS abend processing standard is:

1. LE condition handler intercepts the abend (TRAP(ON))
2. LE produces CEEDUMP to the CICS temporary storage queue (CEEMSG)
3. LE percolates the condition to CICS
4. CICS issues transaction abend (ASRA for protection exception)
5. CICS HANDLE ABEND program logs the error and sends user message
6. CICS transaction dump produced (EXEC CICS DUMP TRANSACTION)

Both the CEEDUMP and the CICS dump are analyzed. The CEEDUMP shows the COBOL-level problem; the CICS dump shows the transaction context.

🔄 Retrieval Practice — Check Your Understanding: 1. What happens if TRAP(OFF) is set and a COBOL program encounters an S0C4? 2. What is a condition token, and what three pieces of information does it carry? 3. In CICS, what transaction abend code corresponds to a COBOL S0C4? 4. From Chapter 2: An S80A during initialization (step 2e or 2g) — does LE's condition handler process it? Or does z/OS handle it directly?

3.6 Analyzing CEEDUMP Output — A Production Skill Every Architect Needs

"If you can read a CEEDUMP, you can diagnose 80% of production COBOL failures in under ten minutes." Kwame makes every architect on his team prove they can read a CEEDUMP before he certifies them for production support rotation.

CEEDUMP Structure

A CEEDUMP has these sections (not all are always present):

┌──────────────────────────────────────────────────────────┐
│  1. HEADER                                                │
│     - Timestamp, enclave ID, thread ID                    │
│     - Reason for dump (condition information)             │
│                                                           │
│  2. TRACEBACK                                             │
│     - Call chain: Main → Sub1 → Sub2 → ... → failing stmt│
│     - Statement numbers and offsets for each call level   │
│     - THIS IS THE MOST IMPORTANT SECTION                  │
│                                                           │
│  3. CONDITION INFORMATION                                 │
│     - Condition token (severity, message number)          │
│     - PSW at time of error                                │
│     - Interrupt code                                      │
│                                                           │
│  4. STORAGE (if CEEDUMP=ON with storage option)           │
│     - Working storage for each program in the call chain  │
│     - Heap segment summary                                │
│     - Stack dump                                          │
│                                                           │
│  5. REGISTER CONTENTS                                     │
│     - General purpose registers at time of error          │
│     - Useful for mapping addresses to working storage     │
│                                                           │
│  6. LE CONTROL BLOCKS                                     │
│     - CAA (Common Anchor Area)                            │
│     - EDB (Enclave Data Block)                            │
│     - Rarely needed for COBOL diagnosis                   │
└──────────────────────────────────────────────────────────┘

Reading a CEEDUMP: A Worked Example

Here is an annotated CEEDUMP from a real (anonymized) production failure at CNB. A batch COBOL program abended S0C7 while processing account records:

CEE3DMP V2 R5.0: Condition processing resulted in the unhandled condition.
 06/15/2022 14:23:47

Information for enclave CNBAR200
   Information for thread 8000000000000001

Traceback:
  DSA   Entry        E Offset  Statement  Load Module  Status
  1     CEEPLPKA     +00000000            CEEPLPKA     Call
  2     CNBAR200     +000042A8  004237    CNBAR200     Exception
  3     CNBVALSB     +00001C04  000892    CNBAR200     Call
  4     CEEMAIN      +00000124            CEEPLPKA     Call

  DSA 2 CNBAR200:
    Condition Information for Active Routines:
      Condition:
        CEE3204S The system detected a data exception (System
                 Completion Code=0C7).
      Location:
        Program Unit: CNBAR200
        Entry:        CNBAR200
        Statement:    4237
        Offset:       +000042A8

How to read this traceback:

1. Start from the bottom. CEEMAIN (DSA 4) is LE's main entry point. It called CNBVALSB (DSA 3), which is a validation subprogram. CNBVALSB called CNBAR200 (DSA 2), where the exception occurred.

Wait — that looks backward. Actually, the call chain is: CEEMAIN → CNBAR200 (the main program) → CNBVALSB (subprogram). The "Entry" at DSA 2 shows CNBAR200 because the exception occurred in CNBAR200 at statement 4237. But note DSA 3 shows CNBVALSB with "Call" status — meaning CNBVALSB called back into CNBAR200, or more likely, the traceback is showing the call chain into the failing module.

The key information: Statement 4237 in CNBAR200 is where the S0C7 occurred.

2. Map the statement to the source. Open the compile listing for CNBAR200. Find statement 4237:

cobol 004237 COMPUTE WS-QUARTERLY-AVG = 004238 WS-ANNUAL-TOTAL / 4

An S0C7 on a COMPUTE means WS-ANNUAL-TOTAL or WS-QUARTERLY-AVG contains invalid packed decimal data.

3. Check the storage dump. The CEEDUMP's storage section shows the working storage for CNBAR200. Find the offset for WS-ANNUAL-TOTAL (from the compile listing's Data Division Map):

``` WS-ANNUAL-TOTAL at offset +000C80, PIC S9(13)V99 COMP-3

Storage at offset +000C80: 000C80: 40404040 40404040 ← X'40' = EBCDIC space characters ```

The field contains spaces — not valid packed decimal. The field was never initialized with a numeric value. The program read a record that should have had a numeric value in this field position, but the record was a header record (all spaces) that the program didn't skip.

4. Root cause identified: The program doesn't check the record type before performing arithmetic on fields that are only numeric in detail records.

This entire diagnosis — from CEEDUMP to root cause — took Kwame four minutes the first time he saw this dump. It takes you longer only because you haven't done it a hundred times yet. Practice.

Key CEEDUMP Fields for Quick Diagnosis

Common CEEDUMP Patterns and What They Mean

After reading hundreds of CEEDUMPs, Kwame has identified recurring patterns that accelerate diagnosis:

Pattern 1: Single-statement S0C7 — uninitialized packed decimal

Condition: CEE3207S The system detected a data exception
           (System Completion Code=0C7).
Statement: 2847

Look at the COBOL source at statement 2847. It's almost always a COMPUTE, ADD, SUBTRACT, MULTIPLY, or DIVIDE operating on a packed decimal field. Check the storage dump for that field — if it contains X'40404040' (EBCDIC spaces) or X'00000000' (binary zeros with an invalid sign nibble), the field was never properly initialized with numeric data.

Production frequency at CNB: 60% of all CEEDUMP-diagnosed abends.

Pattern 2: S0C4 at varying offsets — storage overlay

Condition: CEE3204S The system detected a protection exception
           (System Completion Code=0C4).
Statement: varies (different statement each time)

When the same program abends with S0C4 but at different statements on different runs, suspect a storage overlay. A MOVE or STRING operation earlier in the program is writing past the end of a field, corrupting adjacent working storage. The corruption manifests as S0C4 when the corrupted data is later used as an address or length field.

Diagnosis: Compare multiple CEEDUMPs. Look for a common "upstream" paragraph that runs before each different failure point. That paragraph contains the corrupting MOVE.

Production frequency at CNB: 15% of all CEEDUMP-diagnosed abends. The hardest to resolve — typically requires full storage dump analysis with IPCS.

Pattern 3: U4038 with compatibility level mismatch

CEE3501S LE enclave initialization failed.
  Reason: Load module compiled with incompatible compiler version.
  Module compiled with: Enterprise COBOL V4.2 (Level 11)
  Current LE runtime:   z/OS 2.5 LE V2.5 (Level 14)

The CEEDUMP explicitly states the mismatch. Fix: recompile. No further diagnosis needed.

Production frequency at CNB: 5% historically, 0% since the annual recompilation policy.

Pattern 4: Deep traceback — recursive or deeply nested CALLs

Traceback:
  DSA   Entry        E Offset  Statement
  1     CEEPLPKA     +00000000
  2     MAINPGM      +0000A234  008412    Exception
  3     SUBPGM-A     +00003C10  003204    Call
  4     SUBPGM-B     +00002108  001847    Call
  5     SUBPGM-C     +00001A00  001502    Call
  6     SUBPGM-B     +00002108  001847    Call  ← B calls C calls B?
  7     SUBPGM-C     +00001A00  001502    Call  ← Recursive!
  ...   (many more levels)
  45    CEEMAIN      +00000124

When the traceback shows the same subprograms appearing multiple times, you have recursion — possibly unintentional. The stack grows with each call level. If the recursion is deep enough, the stack exhausts and the program abends with S80A (if during stack expansion) or S0C4 (if the stack overflows into protected storage).

Production frequency at CNB: 5% of CEEDUMP-diagnosed abends. Usually caused by a missing exit condition in a recursive call pattern.

When the CEEDUMP Isn't Enough

Sometimes the CEEDUMP alone doesn't tell the whole story:

Storage overlays: If one field has been corrupted by an adjacent MOVE (a storage overlay), the CEEDUMP shows the corrupted data but not how it was corrupted. For these, you need the full system dump (SYSUDUMP) and eye-readable analysis with tools like IPCS.

Intermittent failures: If the abend occurs once per 50,000 transactions (as in the SecureFirst case from Chapter 2), the CEEDUMP from one failure may not reveal the pattern. You need to collect multiple CEEDUMPs and compare them — looking for common offsets, common data patterns, or common call chains that point to the same root cause.

Multi-program interactions: If the failure involves cross-program storage passing (e.g., a CICS COMMAREA that's too short for the receiving program), the CEEDUMP shows the failure in the receiving program but the bug is in the sending program. The call chain helps, but you may need both programs' compile listings.

LE internal failures: Rarely, the CEEDUMP itself fails — LE's dump routine encounters a problem while formatting the output. When this happens, you get a partial CEEDUMP (truncated at the failure point) and must fall back to the SYSUDUMP. The partial CEEDUMP usually contains enough of the traceback to identify the failing module and statement, but the storage section is incomplete. At CNB, partial CEEDUMPs occur approximately once per year, usually caused by severe storage corruption that also damages LE's control blocks.

🔍 Elaborative Interrogation: Why does LE produce its own dump format (CEEDUMP) instead of relying on the z/OS SYSUDUMP? Think about what LE knows that z/OS does not — specifically, which pieces of information in a CEEDUMP require knowledge of the COBOL program's compile-time structure.

The answer: LE knows the program's Data Division Map (from the compile listing metadata embedded in the load module). This allows LE to format working storage fields with their COBOL names, PIC clauses, and values — information that z/OS does not have. z/OS sees only raw hex storage. LE sees "WS-ACCOUNT-BALANCE PIC S9(13)V99 COMP-3 = 1234567890123.45." This is why CEEDUMP is dramatically more useful than SYSUDUMP for COBOL diagnosis.

🔄 Retrieval Practice — Check Your Understanding: 1. What section of a CEEDUMP should you read first? 2. How do you map a CEEDUMP statement number to the actual COBOL source code? 3. What does X'FEFEFEFE' in a working storage field suggest? (Hint: recall the STORAGE runtime option from Section 3.4.) 4. From Chapter 2: If you see an S80A in the CEEDUMP condition information, what does this tell you about the address space's virtual storage state?

3.7 LE Tuning for Production: Batch and CICS Configurations

This section synthesizes everything into actionable configuration standards. These are the LE configurations that CNB, Pinnacle, SecureFirst, and Federal Benefits have converged on through years of production experience.

Batch Configuration Standard

*================================================================*
* CNB STANDARD CEEUOPT FOR BATCH COBOL PROGRAMS
* Version: 3.1 — Effective 2023-01-01
* Owner: Kwame Mensah, Architecture Team
* Review: Annual (January)
*================================================================*
CNBBATCH CEEXOPT HEAP=(1048576,1048576,ANYWHERE,KEEP,             X
                       67108864,33554432),                         X
                 STACK=(524288,524288,ANYWHERE,KEEP,               X
                        524288,131072),                            X
                 STORAGE=(00,FE,00),                               X
                 ALL31=ON,                                         X
                 TRAP=(ON,SPIE),                                   X
                 ABTERMENC=ABEND,                                  X
                 CEEDUMP=ON,                                       X
                 TERMTHDACT=TRACE,                                 X
                 RPTOPTS=OFF,                                      X
                 RPTSTG=OFF
         END
*
* NOTES:
* 1. HEAP: 1 MB initial/increment below bar; 64 MB/32 MB above bar.
*    Rationale: Avoids dozens of small GETMAIN calls during init.
*    Programs with subprograms benefit most from large initial heap.
*
* 2. STACK: 512 KB initial/increment below bar; 512 KB/128 KB above.
*    Rationale: Sufficient for COBOL call depth < 100 levels.
*    Increase to 1 MB if program has deep PERFORM nesting.
*
* 3. STORAGE(00,FE,00): Always. The 2-5% overhead is non-negotiable.
*    X'FE' in freed storage has caught 14 production bugs since 2019.
*
* 4. TRAP(ON,SPIE): Always. Without TRAP, no CEEDUMP. Without
*    CEEDUMP, no diagnosis. SPIE enables System Programming
*    Interrupt Exit — allows LE to handle program checks.
*
* 5. ABTERMENC=ABEND: Production jobs should ABEND (not return a
*    non-zero RC) on severe conditions. ABEND triggers system dump,
*    automation alerts, and CA-7 restart processing.
*
* 6. RPTSTG=OFF in CEEUOPT — enable via PARM when needed:
*    PARM='/RPTSTG(ON)' on quarterly diagnostic runs.
*    Do not leave ON permanently — minor overhead adds up
*    across 340 batch jobs per night.

CICS Configuration Standard

CICS LE configuration is more complex because options come from multiple sources:

*================================================================*
* CNB STANDARD CEECOPT FOR CICS COBOL PROGRAMS
* Installed in: CEE.SCEERUN (CEECOPT member)
* Version: 2.4 — Effective 2023-01-01
* Owner: Kwame Mensah + CICS Systems Programming
*================================================================*
CNBCICS  CEEXOPT STORAGE=(00,FE,00),                              X
                 ALL31=ON,                                         X
                 TRAP=(ON,SPIE),                                   X
                 CEEDUMP=60,                                       X
                 TERMTHDACT=TRACE,                                 X
                 RPTOPTS=OFF
         END
*
* NOTES:
* 1. HEAP and STACK are managed by CICS DSA — do NOT specify here.
*    CICS allocates per-task storage from its DSAs (CDSA, ECDSA).
*    LE heap/stack options in CEECOPT are IGNORED for CICS tasks.
*
* 2. STORAGE(00,FE,00): Same as batch. Applies to CICS task
*    working storage initialization.
*
* 3. CEEDUMP=60: Limits CEEDUMP to 60 lines per traceback.
*    Full CEEDUMP in CICS writes to temporary storage. If every
*    abending task produces a 500-line CEEDUMP, the temporary
*    storage queue fills quickly. Limit to 60 lines — enough for
*    traceback and condition info; omit full storage dump.
*
* 4. For full storage analysis, use CICS transaction dump (CETR)
*    or CICS auxiliary trace.

CICS SIT Parameters That Affect LE

Pinnacle Health's CICS Tuning After the SOS Incident

After the CICS storage crisis (Chapter 2, Case Study 2), Diane Okoye implemented additional LE tuning:

CEECOPT additions at Pinnacle Health:
  STORAGE=(00,FE,00)       — same as CNB
  CEEDUMP=40               — more aggressive limit (40 lines)
  TERMTHDACT=MSG           — message only (no traceback) for
                             non-critical abends; reduces
                             temporary storage consumption

Diane's reasoning: "In CICS, every abend that produces a full CEEDUMP consumes temporary storage. If a bad deployment causes 500 abends in 60 seconds — like our SOS incident — that's 500 CEEDUMPs competing for storage in a region that's already out of storage. Limiting the CEEDUMP size is a self-defense measure."

SecureFirst Retail Bank: LE for API-Driven COBOL

Yuki Nakamura at SecureFirst faces a different challenge: COBOL programs called via z/OS Connect REST APIs. These programs are invoked by the z/OS Connect server, which creates an LE enclave for each API invocation.

SecureFirst CEEUOPT for API-invoked COBOL:
  HEAP=(65536,65536,ANYWHERE,KEEP,1048576,524288)
  STACK=(65536,65536,ANYWHERE,KEEP,131072,65536)
  STORAGE=(00,FE,00)
  TRAP=(ON,SPIE)
  CEEDUMP=ON
  ABTERMENC=RETCODE    ← Note: RETCODE, not ABEND

The key difference: ABTERMENC=RETCODE. In an API context, an abend would crash the z/OS Connect server thread and potentially affect other API consumers. RETCODE causes LE to set a non-zero return code instead of abending — the z/OS Connect server catches the non-zero return code and sends an HTTP 500 error to the API caller. The API call fails gracefully; the server stays up.

"In batch, you want ABEND because it triggers automation," Yuki explains. "In APIs, you want RETCODE because you can't afford the server going down. Different environments, different choices — but the same LE options."

The IGZETUN Module: Tuning LE for Specific Programs

Beyond CEEUOPT, LE provides the IGZETUN module — a COBOL-specific tuning interface. IGZETUN allows you to specify COBOL-specific runtime behaviors that aren't part of the general LE runtime options:

IGZETUN is less commonly used than CEEUOPT, but it surfaces in performance tuning scenarios. At CNB, the most impactful IGZETUN parameter was INSPECT-CONVERSION=OPTIMIZE, which reduced the elapsed time of a data cleansing program (CNBCLNS1, which performs INSPECT CONVERTING on every record of a 50-million-record file) by 8%.

Monitoring LE Health in Production

Beyond RPTSTG and RPTOPTS, CNB monitors LE health through several operational indicators:

1. LE Abend Rate Tracking: Rob Calloway's operations team tracks LE-specific abend codes (U4036, U4038, U4039, U4093) separately from application abends (S0C4, S0C7, S80A). An LE abend indicates an infrastructure problem — a configuration error, a compatibility issue, or an LE library corruption. Application abends indicate a code problem. The distinction drives different escalation paths.

2. CICS LE Message Queue Monitoring: In CICS, LE writes CEEDUMP output to a temporary storage queue. If the queue grows rapidly (multiple abending transactions), it consumes temporary storage. CNB monitors the LE message queue size and triggers an alert if it exceeds 50 MB — which would indicate a cascading failure like the U4038 incident.

3. Compiler Version Dashboard: The weekly compiler version scan (described in Section 3.7) feeds a dashboard that shows the distribution of compiler versions across all production load modules. Kwame reviews this dashboard monthly. Any program compiled more than 12 months ago is highlighted; any program compiled more than 24 months ago is flagged for immediate recompilation.

Federal Benefits Administration: LE Compatibility Management

Sandra Chen's modernization challenge includes LE compatibility across 340 COBOL programs compiled over 35 years with various compiler versions:

Sandra's approach: "We can't recompile all 340 programs at once — we don't have source for some of them, and others have dependencies that make recompilation risky. So we maintain a compatibility matrix. Before every z/OS upgrade, we test the highest-risk programs against the new LE level. The ones that fail get recompiled first."

Marcus Whitfield's contribution before retirement: a document listing every program's compiler version, LE compatibility level, and known CEEUOPT settings. This document — 47 pages — is one of the most valuable assets Sandra has.

Project Checkpoint: LE Runtime Option Standards for the HA Banking System

Using your HA Banking Transaction Processing System, define LE configuration standards for both environments:

Part 1: Batch LE Configuration

Create the CEEUOPT source for your standard batch configuration:

* YOUR CEEUOPT FOR HA BANKING BATCH PROGRAMS
HABATCH  CEEXOPT HEAP=(________,________,________,________,       X
                       ________,________),                        X
                 STACK=(________,________,________,________,      X
                        ________,________),                       X
                 STORAGE=(____,____,____),                        X
                 ALL31=____,                                      X
                 TRAP=(____,____),                                X
                 ABTERMENC=________,                              X
                 CEEDUMP=____,                                    X
                 TERMTHDACT=________,                             X
                 RPTSTG=____,                                     X
                 RPTOPTS=____
         END

For each option, document your rationale:

Part 2: CICS LE Configuration

Define the CEECOPT settings and CICS SIT parameters for your CICS AORs:

CEECOPT:

CICS SIT:

Part 3: Deployment Verification Checklist

Create a deployment checklist that includes LE verification:

• [ ] Program compiled with current Enterprise COBOL version: __
• [ ] CEEUOPT linked with load module: verified in link-edit listing
• [ ] LE runtime option report (RPTOPTS) reviewed for first deployment
• [ ] CEEDUMP output tested in QA (intentionally trigger an error)
• [ ] Storage report (RPTSTG) collected in QA; high-water mark documented
• [ ] LE version compatibility confirmed for target z/OS level
• [ ] (CICS only) Per-task working storage × concurrent tasks < ECDSA headroom

Deliverable: A two-page LE configuration standard document covering batch and CICS environments, ready for architecture review.

Production Considerations

LE-Related Production Failures: Frequency and Prevention

Based on CNB's incident data from 2019-2023:

LE Upgrade Checklist

Before every z/OS upgrade (which includes an LE upgrade):

1. Identify all unique compiler versions in production load libraries
2. Test highest-risk programs (oldest compiler versions) against new LE
3. Recompile programs that fail compatibility testing
4. Verify CEEUOPT/CEECOPT/CEEDOPT settings are appropriate for new LE level
5. Run RPTOPTS(ON) on first production run after upgrade — verify all options resolved correctly
6. Monitor for U4038 abends in the first week after upgrade

Summary

Language Environment is the runtime foundation for every COBOL program on z/OS. The key takeaways:

1. LE initializes before your first COBOL statement and terminates after your last. The initialization sequence — CEEMAIN → enclave creation → thread creation → heap/stack/WS allocation → condition handler registration — takes milliseconds but sets up the entire runtime environment.

2. Enclaves are the unit of program execution. In batch: one enclave per job step, lives for minutes to hours. In CICS: one enclave per task, lives for milliseconds. Everything in the enclave — heap, stack, files, conditions — is freed when the enclave terminates.

3. Runtime options are the architect's control panel. CEEUOPT (highest priority, linked with program) overrides PARM (JCL), which overrides CEECOPT/CEEDOPT (installation defaults). The essential options: HEAP, STACK, STORAGE, TRAP, ABTERMENC, CEEDUMP, RPTSTG, RPTOPTS.

4. Condition handling determines what happens when your program fails. TRAP(ON) enables LE to intercept hardware interrupts and produce CEEDUMPs. Without TRAP(ON), you get raw system dumps instead of COBOL-level diagnostics.

5. CEEDUMPs are the primary diagnostic tool for production COBOL failures. The traceback section shows the exact statement and call chain. The condition information shows the error type. The storage section shows the data. Reading a CEEDUMP is a required skill for every COBOL architect.

6. Batch and CICS LE configurations are fundamentally different. Batch uses CEEUOPT and PARM for options; CICS uses CEECOPT and SIT parameters. Heap and stack are managed by LE in batch and by CICS DSAs in CICS. ABTERMENC should be ABEND in batch (for automation) and may be RETCODE in API environments (for graceful failure).

What's Next

In Chapter 4, we move from the runtime environment to the data layer: z/OS Dataset Management and Access Methods. You now understand how your program's storage is allocated (Chapter 2) and how the runtime environment is configured (this chapter). Next, you'll understand how data gets from DASD into that storage — VSAM, QSAM, BSAM, and the access method services that connect your COBOL I/O statements to physical datasets. The buffer storage you sized in Chapter 2 and the file I/O that LE manages (this chapter) come together in the access method layer.