File status 97: OPEN successful, file integrity verified

What it means

When a job ends without closing a VSAM data set it had open for output, the catalog still shows the data set as open, and its end-of-data information may be out of date. The next OPEN notices. VSAM's OPEN returns register 15 = 4, a warning, with error code 116 (X'74') when the high-used RBA wasn't verified, or 118 (X'76') when VSAM's own implicit verify corrected it. Once the end-of-data information has been verified, Enterprise COBOL completes the OPEN and reports status 97.

Status 97 is for VSAM only. It means success, but its first digit is 9, and that causes trouble. Programs that test for 00 treat it as a failure. Enterprise COBOL 5.2 also started running the error declarative after a 97, which earlier releases didn't do (IBM APAR PI85868). IBM's answer was the VSAMOPENFS compiler option. VSAMOPENFS(COMPAT), the default, keeps returning 97. VSAMOPENFS(SUCC) returns 00 for the same OPEN.

The data may still be incomplete. Verifying corrects the catalog's record of where the data ends. It doesn't recover anything the failed job never wrote. Records that job meant to add may be missing, and a rerun of it can add some of them twice.

Common causes

• A previous job that had the cluster open for output abended or was cancelled before its CLOSE.
• A CICS region or another long-running address space ended abnormally with the file open.
• A TSO session or file editing tool timed out while it had the data set open for update.
• A system failure while the data set was open.

How to find the problem

1. Look in the job log for IEC161I warning messages for the ddname. VSAM issues them when OPEN finds the data set wasn't closed properly.
2. Display data-name-8 after the OPEN. Return code 4 with error code 116 or 118 confirms the improperly closed case.
3. Check the scheduler history for the last job that updated the cluster, and how it ended.
4. Check the options page of the compiler listing for VSAMOPENFS.

How to fix it

• Treat 97 as a successful OPEN in your status checks, or compile with VSAMOPENFS(SUCC) so the program sees 00.
• Find out why the earlier job didn't close the file, and fix that job or its restart procedure.
• After a failure in a job that updates the cluster, check the data. Compare record counts with what the job should have written, and restore from backup if needed.
• Add an IDCAMS VERIFY step to the recovery procedure for jobs that update the cluster, so the catalog is corrected before other jobs open it.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Enterprise COBOL documentation for your release.