Key Takeaways — Chapter 10: Defensive Programming

Core Philosophy

  1. Never assume success. Every I/O operation, every arithmetic computation, every external data field can fail. Check everything.

  2. Fail loudly. A silent failure that corrupts data is infinitely worse than a noisy ABEND that alerts the operator.

  3. Fail safely. When stopping, leave data in a consistent state: close files, set return codes, write a final log entry.

  4. Log everything. Every error needs a timestamp, program name, paragraph name, and enough context to diagnose the problem at 2 AM.

FILE STATUS

  1. Declare FILE STATUS for every file. No exceptions. Define 88-level condition names for the status codes you expect.

  2. Check FILE STATUS after every I/O operation. OPEN, READ, WRITE, REWRITE, DELETE, START, and CLOSE. All of them.

  3. The OPEN check is the most critical. A failed OPEN means every subsequent operation on that file will also fail. Detect it immediately.

  4. Understand the status code categories. 0x = success, 1x = end condition, 2x = invalid key, 3x = permanent error, 4x = logic error, 9x = vendor-specific.

Error Handlers

  1. ON SIZE ERROR catches arithmetic overflow and divide-by-zero. It does NOT catch decimal truncation.

  2. INVALID KEY handles key-related errors on indexed and relative files. Common codes: '22' (duplicate), '23' (not found), '24' (boundary violation).

  3. DECLARATIVES provide automatic error handling for permanent I/O errors. Use them as a safety net, not as the primary error handler.

Input Validation

  1. Always test IS NUMERIC before arithmetic on external data. This prevents S0C7 ABENDs from corrupted packed-decimal fields.

  2. Use tiered validation. Level 1: field-level. Level 2: cross-field. Level 3: referential. Each level catches a different class of error.

  3. Collect all errors per record. Do not stop at the first error — multiple errors in one record provide better diagnostics.

Patterns

  1. Error threshold pattern. Set both total and consecutive error limits. Consecutive errors reveal systemic data problems (wrong file, format change).

  2. Bypass pattern. For non-critical operations, log the error and continue. Not every failure should stop the program.

  3. Retry pattern. For transient errors (file locks), retry a limited number of times before failing.

  4. Graceful ABEND. Log, close all files, set RC-FATAL, STOP RUN. Never leave files unclosed.

Return Codes

  1. Use the standard convention. 0 = success, 4 = warning, 8 = error, 12 = severe, 16 = fatal.

  2. JCL checks condition codes. Subsequent job steps can skip based on the return code, preventing cascade failures.