File status 93: Resource not available

What it means

Status 93 is an implementor-defined error. IBM's description is just that a resource was not available, and it applies to every file type except QSAM. In practice it nearly always involves VSAM sharing.

At OPEN, the usual VSAM code behind it is error code 168 (X'A8'). It means the data set isn't available for the type of processing requested, typically because another address space has the cluster open and its SHAREOPTIONS don't allow this open as well. A CICS region with the file open for update, or another batch job writing to it, are the classic cases.

On a READ or other request, 93 can come from register 15 = 8 with feedback code 20 (X'14'). Without record-level sharing, that code means another request already holds the record, or its control interval, under exclusive control. The second status area (data-name-8 of the FILE STATUS clause) shows which of these you have.

Common causes

• A CICS region has the file open and a batch job tries to open it for update.
• Another batch job has the cluster open for output. With SHAREOPTIONS 1, one job can update or many can read, but not both at once. With SHAREOPTIONS 2, readers can run alongside one updater, but a second updater is refused.
• A record or control interval is held under exclusive control by another request when this READ for update or WRITE runs.

How to find the problem

1. Display data-name-8. On OPEN, error code 168 points to a sharing conflict. On a request, return code 8 with feedback 20 points to exclusive control.
2. Check the job log for VSAM OPEN messages for the ddname.
3. Find who holds the data set. In CICS, CEMT INQUIRE FILE shows whether the file is open. On z/OS, the operator command D GRS, or the ENQ display in ISRDDN, shows which jobs hold enqueues on the data set.
4. Run IDCAMS LISTCAT ALL and note SHROPTNS for the cluster.

How to fix it

• Close the file in CICS before the batch update with CEMT SET FILE(name) CLOSED, and open it again afterwards. Many shops automate this in the batch schedule.
• Schedule batch jobs that update the same cluster so they don't overlap.
• Review SHAREOPTIONS with care. A higher setting such as 3 lets more jobs open the cluster, but VSAM then leaves data integrity to you.
• If batch and online really must update at the same time, look at VSAM record-level sharing (RLS) or DFSMStvs.
• For exclusive control conflicts, retry after a short wait, or change the logic so one task doesn't hold a record while another updates 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.