Why FILE STATUS Matters
Every OPEN, CLOSE, READ, WRITE, REWRITE, DELETE, and START statement in COBOL sets a two-character status value that reports exactly what happened, and declaring FILE STATUS IS WS-FILE-STATUS in the SELECT clause captures it into a WORKING-STORAGE field a program can inspect immediately after the I/O statement. Relying solely on AT END or INVALID KEY tells a program that something went wrong but not precisely what, whereas the status code distinguishes a clean end-of-file ('10') from a duplicate key ('22'), a record-not-found ('23'), or a boundary violation ('34'), which is essential for writing robust batch jobs that must log, retry, or abort based on the specific failure.
Cricket analogy: A vague AT END is like a scoreboard that only shows 'OUT', while FILE STATUS is like the detailed dismissal note — 'caught behind off Bumrah' — that tells you exactly how and why, not just that it happened.
Common Status Code Categories
Status codes are grouped by their leading digit: '0x' codes (00, 02, 04, 05) indicate successful completion with minor notes, such as '00' for a clean success or '02' for a successful read with a duplicate alternate key; '1x' codes signal AT END conditions, primarily '10'; '2x' codes cover invalid key situations, including '21' for a sequence error on WRITE, '22' for a duplicate key on WRITE, and '23' for record-not-found on READ or DELETE; '3x' codes report permanent I/O errors such as '34' for a boundary violation (disk full or beyond file limits) or '35' for opening a file that does not exist; and '9x' codes are vendor- or environment-specific extensions, commonly seen for logic errors like attempting to WRITE to a file opened INPUT.
Cricket analogy: The '0x' success codes are like a clean single or four being scored — routine, positive outcomes — while '3x' codes resemble a run-out due to a broken stump, a hard failure requiring review.
Coding Defensive Status Checks
Best practice is to check WS-FILE-STATUS immediately after every I/O verb rather than relying on INVALID KEY or AT END alone, typically with an EVALUATE that branches on '00' and '02' as success, '10' as expected end-of-file, and anything else as an error routed to a common error-handling paragraph that displays the status, the file name, and often abends the job via CALL 'CEE3ABD' or a similar routine so operations staff see a clear failure rather than silently corrupted output. Many shops define a copybook of 88-level condition names against the status field, such as 88 FS-SUCCESS VALUE '00' '02' and 88 FS-EOF VALUE '10', making the EVALUATE or IF logic read naturally and consistently across every program in the codebase.
Cricket analogy: Checking status after every I/O verb is like a captain reviewing the third umpire's decision after every close call rather than assuming the on-field call was correct — thorough verification at each step.
01 WS-FILE-STATUS PIC X(2).
88 FS-SUCCESS VALUE '00' '02'.
88 FS-EOF VALUE '10'.
88 FS-DUPLICATE-KEY VALUE '22'.
88 FS-NOT-FOUND VALUE '23'.
READ-PARAGRAPH.
READ CUSTOMER-FILE
EVALUATE TRUE
WHEN FS-SUCCESS
PERFORM PROCESS-RECORD
WHEN FS-EOF
MOVE 'Y' TO WS-EOF-FLAG
WHEN FS-NOT-FOUND
DISPLAY 'RECORD NOT FOUND'
WHEN OTHER
DISPLAY 'FILE ERROR STATUS: ' WS-FILE-STATUS
PERFORM ABEND-JOB
END-EVALUATE.IBM Enterprise COBOL also supports an extended, four-character status field (declared as PIC X(4) in some environments) where the last two characters carry a VSAM-specific return code, giving even finer diagnostic detail than the standard two-character status alone.
Never assume '00' after every I/O statement without checking. A batch job that ignores FILE STATUS and only traps AT END can silently continue processing after a genuine I/O error, corrupting downstream output while appearing to run successfully.
- FILE STATUS IS captures a two-character diagnostic code after every file I/O statement.
- '0x' codes indicate success, '1x' end-of-file, '2x' invalid key conditions, '3x' permanent errors, '9x' logic errors.
- '00' and '02' are successful outcomes; '10' is the standard end-of-file code.
- '22' signals a duplicate key on WRITE; '23' signals record-not-found on READ or DELETE.
- 88-level condition names improve readability of status checks in EVALUATE or IF logic.
- Best practice checks status after every I/O verb, not just via AT END or INVALID KEY.
- Unhandled non-success statuses should route to a common error paragraph that logs and can abend the job.
Practice what you learned
1. What does FILE STATUS code '23' typically indicate?
2. Which status code range indicates a permanent I/O error such as a boundary violation?
3. What is the purpose of declaring 88-level condition names against WS-FILE-STATUS?
4. Why is checking FILE STATUS after every I/O verb considered best practice over relying solely on AT END?
5. Which status code indicates a clean, successful I/O operation?
Was this page helpful?
You May Also Like
Indexed File Processing (VSAM)
Understand how COBOL uses indexed files, typically backed by VSAM KSDS on mainframes, to perform fast random and sequential access by key.
Sequential File Processing
Learn how COBOL reads, writes, and updates records in a sequential file, the oldest and most common file organization in mainframe batch systems.
SORT and MERGE in COBOL
Learn how COBOL's built-in SORT and MERGE verbs reorder and combine files using the language's native sort work file mechanism.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics