Appendix I: ABEND Code Reference

Overview

An ABEND (Abnormal End) occurs when a z/OS program or task terminates due to an unrecoverable error. Each ABEND produces a code that identifies the type of failure. System ABEND codes, assigned by z/OS, begin with the letter "S" followed by a three-character hexadecimal value (e.g., S0C7). User ABEND codes, issued by application programs, begin with "U" followed by a four-digit decimal number (e.g., U4038).

This appendix covers the ABEND codes most frequently encountered by COBOL programmers, including their causes, diagnostic procedures, and corrective actions. For each code, the emphasis is on how COBOL programming errors produce the ABEND and what to look for in the diagnostic output.

Reading ABEND Codes in Job Output

When a job ABENDs, the JES job log displays a message similar to:

IEF472I JOBNAME STEPNAME - COMPLETION CODE - SYSTEM=0C7 USER=0000

The SYSTEM field contains the system ABEND code (without the "S" prefix). The USER field contains the user ABEND code. The CICS region log or transaction dump provides equivalent information for online ABENDs.

System ABEND Codes

S001 -- I/O Error

Full Name: I/O Error on Data Set

Common Causes in COBOL: - Writing to a dataset that has reached its maximum extent allocation and no secondary space was specified in the JCL - Reading from a dataset that has a physical I/O error on the storage device - Attempting to write a record that exceeds the dataset's maximum record length (LRECL mismatch between the COBOL program and the JCL or dataset definition) - Block size conflict between the program's FD entry and the JCL DCB parameters

Diagnostic Steps: 1. Check the JCL SYSOUT or job log for the IEC message that precedes the ABEND -- it identifies the specific DD name and dataset 2. Verify that LRECL and BLKSIZE in the JCL match the record description in the COBOL FD entry 3. Check for space allocation in the JCL DD statement (primary and secondary space) 4. Verify the dataset's record format (RECFM) matches the program's expectations

Corrective Action: - Align LRECL, BLKSIZE, and RECFM between JCL and COBOL FD - Increase space allocation if the dataset ran out of space - For physical I/O errors, restore the dataset from backup and rerun

S013 -- Dataset Attribute Mismatch

Full Name: Conflicting DCB Parameters

Common Causes in COBOL: - The record length defined in the COBOL FD (RECORD CONTAINS clause) does not match the LRECL of the existing dataset - The RECFM of the dataset (F, FB, V, VB) does not match the COBOL program's assumptions (e.g., program writes variable-length records to a fixed-length dataset) - Opening an existing dataset with different DCB attributes than those stored in the catalog - Block size incompatibility

Diagnostic Steps: 1. Check the IEC141I or IEC143I message in the job log for the specific attribute conflict 2. Use ISPF option 3.4 or LISTCAT to examine the existing dataset's attributes 3. Compare the dataset's LRECL, BLKSIZE, and RECFM with the COBOL program's FD entry and the JCL DD statement

Corrective Action: - Correct the COBOL program's FD entry or the JCL DCB parameters to match the dataset - If creating a new dataset, ensure the JCL specifies the correct attributes - If the dataset is incorrect, delete and reallocate it with the correct attributes

S0C1 -- Operation Exception

Full Name: Operation Exception (Program Interrupt Code 01)

Common Causes in COBOL: - Calling a subprogram that does not exist in the load library (STEPLIB/JOBLIB) - A missing or corrupted load module - Branching to an invalid address due to a corrupted program table or overlaid storage - Calling a program name that is blank or contains invalid characters

Diagnostic Steps: 1. Check the PSW (Program Status Word) address in the dump to identify the failing instruction 2. Verify that the called program name in the CALL statement matches the PROGRAM-ID in the subprogram 3. Confirm the subprogram's load module exists in the STEPLIB or JOBLIB concatenation 4. Check for storage overlay by examining the program's storage areas for unexpected content

Corrective Action: - Add the correct load library to the STEPLIB DD concatenation - Recompile and relink the called subprogram - If the CALL uses a variable (CALL WS-PROGRAM-NAME), verify the variable contains the correct program name

S0C4 -- Protection Exception

Full Name: Protection Exception (Program Interrupt Code 04)

Common Causes in COBOL: - Referencing a table (OCCURS) with a subscript or index that is out of bounds, addressing storage outside the program's allocated memory - Using an uninitialized pointer or reference to LINKAGE SECTION data when the data was not properly passed by the calling program - Processing a file that was not opened (OPEN statement missing or failed) - CICS programs referencing a COMMAREA that was not passed (EIBCALEN = 0 but program accesses DFHCOMMAREA) - Moving data to or from an area that the program does not have permission to access

Diagnostic Steps: 1. Examine the PSW address and the COBOL compiler listing to identify the failing statement 2. Check all table subscripts and indexes for boundary violations -- compile with the SSRANGE option to enable runtime subscript checking 3. Verify that all files are opened before being read, written, or closed 4. In CICS, verify EIBCALEN is checked before accessing DFHCOMMAREA 5. Examine LINKAGE SECTION parameters to ensure the calling program passes all expected parameters

Corrective Action: - Add bounds checking for all table subscripts (IF WS-INDEX > 0 AND WS-INDEX <= table-size) - Compile with SSRANGE during testing to catch out-of-bounds references automatically - Add OPEN verification logic (check FILE STATUS after every OPEN) - In CICS, always check EIBCALEN before accessing the COMMAREA

S0C5 -- Addressing Exception

Full Name: Addressing Exception (Program Interrupt Code 05)

Common Causes in COBOL: - A null or invalid address in a pointer or base register, often caused by an uninitialized LINKAGE SECTION reference - Calling a subprogram with fewer parameters than the subprogram expects, leaving LINKAGE SECTION items unaddressed - Using SET ADDRESS OF to point to an invalid memory location - Corrupted BLL cells in older CICS programs

Diagnostic Steps: 1. Check the PSW address against the compiler listing to locate the failing statement 2. Verify the CALL statement passes the same number of parameters as the called program's USING clause 3. Check for null addresses in pointer data items 4. In CICS, verify COMMAREA handling and BLL cell management

Corrective Action: - Ensure CALL parameter counts match between caller and callee - Add null-address checks before referencing LINKAGE SECTION data - Recompile both the calling and called programs to ensure consistent parameter definitions

S0C6 -- Specification Exception

Full Name: Specification Exception (Program Interrupt Code 06)

Common Causes in COBOL: - A COMP (binary) data item is not aligned on the correct boundary (halfword for 2-byte, fullword for 4-byte, doubleword for 8-byte) - An instruction references an operand at an odd address when an even address is required - Misuse of REDEFINES or incorrect record layout causing binary fields to fall on wrong boundaries

Diagnostic Steps: 1. Check the failing instruction address in the dump against the compiler listing 2. Look for COMP or BINARY data items that are subordinate to a group item at an odd offset 3. Review any REDEFINES clauses that might misalign binary fields 4. Check the COBOL compiler listing for BL (Base Locator) and displacement values of suspected data items

Corrective Action: - Use the SYNCHRONIZED (SYNC) clause on binary data items to force correct alignment - Restructure record layouts to naturally align binary fields on appropriate boundaries - Alternatively, use COMP-3 (packed decimal) which has no alignment requirement

S0C7 -- Data Exception

Full Name: Data Exception (Program Interrupt Code 07)

Common Causes in COBOL: - Performing arithmetic on a numeric (COMP-3 or DISPLAY numeric) field that contains non-numeric data (spaces, low-values, or garbage) - A COMP-3 field with an invalid sign nibble (the last nibble must be C, D, or F; any other value causes S0C7) - Moving data from a group item (which is treated as alphanumeric) to a numeric field without validation - An uninitialized WORKING-STORAGE numeric field used in arithmetic before being populated - Reading a file record that does not match the expected format and using its fields in arithmetic

Diagnostic Steps: 1. This is the most common ABEND for COBOL programmers. Locate the failing instruction using the PSW address and compiler listing 2. Identify which data item was involved in the operation at the point of failure 3. Display or dump the contents of the data item in hexadecimal to see what it actually contains 4. Check if the field was properly initialized (VALUE clause or INITIALIZE statement) before use 5. Check if input data was validated before arithmetic

Corrective Action: - Always INITIALIZE numeric work areas before use - Validate input data with IS NUMERIC class condition before performing arithmetic - Check FILE STATUS after every READ to detect I/O errors before processing the record - Use VALUE clauses on WORKING-STORAGE numeric items - Compile with the TEST(SEPARATE) option to generate symbolic debug information that makes diagnosis easier

S0CB -- Division by Zero

Full Name: Fixed-Point Divide Exception (Program Interrupt Code 0B)

Common Causes in COBOL: - DIVIDE statement or COMPUTE with division where the divisor is zero - Calculating an average (total / count) when the count is zero - A loop counter or accumulator that should have been incremented but was not, resulting in division by zero

Diagnostic Steps: 1. Locate the failing DIVIDE or COMPUTE statement using the PSW address 2. Examine the divisor data item's value at the time of the ABEND

Corrective Action: - Always test the divisor before division: IF WS-DIVISOR NOT = ZERO - Use the ON SIZE ERROR phrase on DIVIDE and COMPUTE statements to catch division by zero at runtime - Initialize all counters and accumulators before use

S106 -- Module Not Found (LINK/ATTACH)

Full Name: Load Module Not Found

Common Causes in COBOL: - The program specified on the EXEC PGM= JCL statement does not exist in any library in the search order (STEPLIB, JOBLIB, link list, LPA) - A dynamic CALL to a subprogram whose load module is not in the STEPLIB concatenation - The program name is misspelled in the JCL or CALL statement

Diagnostic Steps: 1. Verify the program name in the JCL EXEC statement or COBOL CALL statement 2. Check the STEPLIB or JOBLIB DD concatenation to confirm the correct load library is included 3. Verify the program has been compiled, link-edited, and placed in the load library

Corrective Action: - Add the correct load library to the STEPLIB DD - Compile, link-edit, and install the missing program - Correct any program name misspellings

S806 -- Module Not Found (Specific)

Full Name: Module Not Found During LOAD/LINK/ATTACH

Common Causes in COBOL: - Very similar to S106 but occurs at a different point in the load process - The load module exists in the library but has an unresolved external reference (a called subprogram was not included in the link-edit step) - A COBOL CALL statement references a program that was not link-edited into the load module or load library

Diagnostic Steps: 1. The system message (IEW2456E or similar) identifies the specific missing module 2. Check the link-edit (IEWL/binder) listing for unresolved external references 3. Verify all subprograms referenced by CALL statements are included in the link-edit

Corrective Action: - Include all required subprogram object modules in the link-edit step - Verify STEPLIB includes all required load libraries - Relink the main program with all dependent subprograms

S122 -- Job Canceled by Operator

Full Name: Job Canceled by Operator or System

Common Causes in COBOL: - An operator issued a CANCEL command for the job (P or C command on the console) - The job exceeded a resource limit (time, output lines) and was canceled by the system or automation

Diagnostic Steps: 1. Check the job log for the cancellation message, which identifies who or what canceled the job 2. Look for IEF352I or similar messages indicating the cancellation reason

Corrective Action: - If canceled for excessive resource usage, optimize the program or increase limits - If canceled by an operator, determine the reason (stuck job, wrong execution, production issue) - If canceled by automation, review the automation rules and job scheduling

S222 -- Job Canceled by User (TSO)

Full Name: Job Canceled by Submitting User

Common Causes in COBOL: - The TSO user who submitted the job issued a CANCEL command - Similar to S122 but specifically triggered by the submitting user

Diagnostic Steps and Corrective Action: Same as S122.

S322 -- CPU Time Limit Exceeded

Full Name: Time Limit Exceeded

Common Causes in COBOL: - An infinite loop in the PROCEDURE DIVISION (PERFORM UNTIL condition that never becomes true) - A program processing far more records than expected due to an incorrect input file or missing end-of-file condition - The TIME parameter on the JOB or EXEC statement is too small for the volume of work

Diagnostic Steps: 1. Check which step timed out (the IEF352I message identifies the step) 2. Examine the program for infinite loops -- look for PERFORM UNTIL with conditions that might never be satisfied 3. Check that all READ loops have proper AT END handling and that the end-of-file flag is actually being tested 4. If the program is processing correctly but slowly, check the TIME parameter

Corrective Action: - Fix infinite loops by correcting the loop termination condition - Ensure every READ has AT END that sets an end-of-file flag, and the flag is tested in the PERFORM UNTIL condition - Increase the TIME parameter if the processing volume legitimately requires more time - Add checkpoint/restart logic for long-running batch programs

S804 -- Insufficient Virtual Storage

Full Name: Insufficient Virtual Storage (GETMAIN Failed)

Common Causes in COBOL: - The program requires more memory than the REGION parameter allows - Very large WORKING-STORAGE areas (large tables, numerous record definitions) - A storage leak caused by repeated dynamic CALL without CANCEL releasing the subprogram's storage

Diagnostic Steps: 1. Check the REGION parameter on the JOB or EXEC statement 2. Examine the COBOL program's WORKING-STORAGE for large data areas 3. Check for dynamic CALL patterns that might accumulate loaded subprograms

Corrective Action: - Increase the REGION parameter (REGION=0M for unlimited) - Reduce WORKING-STORAGE size by using files instead of in-memory tables - Use CANCEL to release dynamically loaded subprograms when no longer needed

S913 -- Security Authorization Failure

Full Name: RACF Security Authorization Failed

Common Causes in COBOL: - The job's user ID does not have READ or UPDATE authority to a dataset referenced in the JCL - Attempting to open a dataset for OUTPUT or I-O without WRITE permission - Accessing a DB2 database or CICS resource without the required RACF profile authorization

Diagnostic Steps: 1. Check the ICH408I message in the job log, which identifies the dataset and the type of access that was denied 2. Verify the user ID has the required access level (READ, UPDATE, ALTER) in the RACF profile for the dataset

Corrective Action: - Request appropriate RACF access from the security administrator - Verify the correct dataset name is specified (typos in DSN can reference datasets you do not have access to) - If the program only needs to read the dataset, ensure it opens the file for INPUT, not I-O or OUTPUT

Common User ABEND Codes

User ABEND codes are issued by application programs, middleware (CICS, DB2), and vendor products. The following codes are frequently encountered by COBOL developers.

U0016 -- COBOL SORT/MERGE Error

Common Causes: The SORT or MERGE statement failed, typically due to insufficient sort work space, an invalid sort key definition, or an error in the INPUT or OUTPUT PROCEDURE.

Corrective Action: Check the sort work DD statements for adequate space allocation. Verify that SORT key fields match the actual record layout. Check for errors in INPUT/OUTPUT PROCEDURE paragraphs.

U0456 -- CICS Program Error

Common Causes: A CICS application program issued an EXEC CICS ABEND command with code 0456, typically indicating an unrecoverable application error detected by the program's own error handling.

Corrective Action: Review the application's error handling logic to determine what condition triggered the ABEND. Check CICS auxiliary trace or transaction dump for details.

U1026 -- DB2 Unavailable

Common Causes: A COBOL program attempted to execute an SQL statement, but the DB2 subsystem is not available or the program's plan or package cannot be found.

Corrective Action: Verify DB2 is active. Verify the program's plan or package has been bound. Ensure the correct DB2 subsystem name is specified in the JCL.

U4038 -- DB2 Call Attach Error

Common Causes: The program's DB2 plan could not be found, or the plan was invalidated because underlying database objects were altered (ALTERed or DROPped and recreated) since the last BIND.

Corrective Action: Rebind the program's DB2 plan or package. Verify the plan name matches the program name or the plan specified in the JCL.

U4093 -- DB2 Resource Unavailable

Common Causes: A DB2 resource (tablespace, index, or database) needed by the program is in a stopped, restricted, or utility-active state.

Corrective Action: Check the DB2 resource status with DISPLAY DATABASE command. Start the resource or wait for the utility to complete.

Diagnostic Best Practices for COBOL ABEND Analysis

Always check the job log first. The system messages preceding the ABEND often identify the exact cause. Look for IEC (I/O), ICH (security), IEW (link-edit), and IGZ (COBOL runtime) messages.
Use the compiler listing. Compile with MAP and LIST options to generate the Data Division Map and Assembler listing. The PSW address from the dump can be mapped to a specific COBOL statement using the assembler listing.
Compile with debugging options during development. SSRANGE catches subscript errors. TEST generates symbolic debug information. These options add overhead and should be removed for production, but they dramatically accelerate debugging.
Check FILE STATUS after every I/O operation. Many S001 and S013 ABENDs can be prevented by checking FILE STATUS and handling errors gracefully rather than letting the ABEND occur.
Validate data before arithmetic. The S0C7 is the single most common COBOL ABEND. Validate that fields contain numeric data (IS NUMERIC test) before using them in arithmetic or MOVE to numeric items. Initialize all WORKING-STORAGE numeric items with VALUE clauses.
Verify parameter consistency. S0C4 and S0C5 ABENDs in called subprograms are frequently caused by parameter mismatches between the CALL statement and the LINKAGE SECTION. Ensure the number, size, and type of parameters match exactly.
Use CEDF for CICS debugging. The CICS Execution Diagnostic Facility (CEDF) allows you to step through a CICS transaction command by command, examining COMMAREA contents, response codes, and exception conditions before they cause ABENDs.
Capture and review dumps. Request a SYSUDUMP, SYSABEND, or SYSMDUMP DD in JCL to capture diagnostic information when an ABEND occurs. The dump contains storage contents, register values, and program trace data essential for complex problem diagnosis.