Error Handling: FILE STATUS Codes & Exception Handling

COBOL Intermediate/Advanced

Chapter 6 · Error Handling: FILE STATUS Codes & Exception Handling

Fundamentals' own Chapter 8 covered three real codes — 00, 10, 35 — enough to get a sequential program working. Real production systems distinguish far more real conditions than that, and repeating a check after every single I/O statement gets unwieldy fast. Two things fix that: a fuller real code vocabulary, and a genuinely different place to put the handling logic.

FILE STATUS: The Real Category Structure

Every real two-character FILE STATUS value's own first character marks a genuine category of outcome:

First Digit	Real Category
0	Successful completion
1	At end (real end-of-file conditions)
2	Invalid key (real random/keyed-access failures)
3	Permanent error
4	Logic error — the file used incorrectly by the program itself
9	Implementor-defined

A Fuller Real Code Reference

Code	Real Meaning
23	Record not found — a real random READ's key genuinely doesn't exist
22	Duplicate key on a WRITE to an indexed file
35	File not found on OPEN INPUT/I-O — Fundamentals' own real example
41	OPEN attempted on a file already genuinely open
46	Sequential READ attempted with no real current record established
47	READ attempted on a file not genuinely opened for input
48	WRITE attempted on a file not genuinely opened for output
49	REWRITE/DELETE attempted on a file not genuinely opened I-O

A Genuinely Useful Pattern Codes 4x are real logic errors — the program's own code did something the file's current open mode doesn't support (like this chapter's own 47/48/49) — distinct from a real 3x permanent error, which reflects a genuine problem with the file or device itself rather than a mistake in the calling program.

The Real Repetition Problem

Every real file-handling example since Fundamentals Chapter 8 has repeated a check — AT END, INVALID KEY, or a manual IF WS-FILE-STATUS NOT = "00" — after every single I/O statement. A real program touching one file dozens of times ends up with that same handling logic copied dozens of times too.

DECLARATIVES: Real, Centralized Error Handling

A real DECLARATIVES section, placed before a program's own main PROCEDURE DIVISION logic, lets one USE-headed section handle every genuine error on a named file automatically — no INVALID KEY or AT END clause needed on the individual statements at all:

PROCEDURE DIVISION.
DECLARATIVES.
CUSTOMER-FILE-ERROR SECTION.
    USE AFTER STANDARD ERROR PROCEDURE ON CUSTOMER-FILE.
CUSTOMER-FILE-ERROR-PARA.
    EVALUATE WS-FILE-STATUS
        WHEN "23"
            DISPLAY "RECORD NOT FOUND"
        WHEN "35"
            DISPLAY "FILE NOT FOUND"
            MOVE 16 TO RETURN-CODE
            STOP RUN
        WHEN OTHER
            DISPLAY "UNEXPECTED FILE ERROR: " WS-FILE-STATUS
            MOVE 16 TO RETURN-CODE
            STOP RUN
    END-EVALUATE.
END DECLARATIVES.

Genuinely Automatic, Not Just Reorganized USE AFTER STANDARD ERROR PROCEDURE ON CUSTOMER-FILE genuinely runs this whole paragraph automatically whenever any I/O statement against CUSTOMER-FILE — a READ, a WRITE, a REWRITE, whatever — produces a non-successful real status. Every future READ CUSTOMER-FILE elsewhere in the program can genuinely drop its own INVALID KEY/AT END clause entirely, since this one declared section already covers it.

Hands-On Exercises

Exercise 1

Using this chapter's own real FILE STATUS category table, explain in your own words the genuine difference between a real code 35 (category 3) and a real code 47 (category 4), and why they represent two structurally different kinds of problem rather than both simply being "errors."

📄 View solution

Exercise 2

Using this chapter's own real DECLARATIVES example, explain in your own words what genuinely happens the next time a plain READ CUSTOMER-FILE statement (with no INVALID KEY clause of its own) encounters a real code 23, and why that doesn't cause the program to crash or leave the error unhandled.

📄 View solution

Exercise 3

Using this chapter's own real material, explain in your own words the genuine tradeoff a program takes on by moving all of CUSTOMER-FILE's own error handling into one DECLARATIVES section, compared with handling each individual I/O statement's own INVALID KEY or AT END clause separately, inline, at the point it occurs.

📄 View solution

Chapter 6 Quick Reference

FILE STATUS category (first digit) — 0 success, 1 at end, 2 invalid key, 3 permanent error, 4 logic error, 9 implementor-defined
Common real codes — 22 duplicate key, 23 record not found, 35 file not found on OPEN, 41 already open, 46-49 real mode-mismatch logic errors
DECLARATIVES ... END DECLARATIVES — a real, separate PROCEDURE DIVISION section holding centralized error-handling logic
USE AFTER STANDARD ERROR PROCEDURE ON file-name — genuinely, automatically invoked on any non-successful I/O against that file, with no per-statement INVALID KEY/AT END needed