AEIS: NOTOPEN not handled

What it means

NOTOPEN means the resource a command needs isn't open and CICS won't open it for this request. It comes up most often with file control. A CICS file that is closed but enabled is opened automatically by the first request that needs it. A file that an operator closed is left closed and unenabled, and requests against it get NOTOPEN until someone opens it again. A request can also get NOTOPEN while a close is in progress, or when CICS tries to open the file and the open fails.

Transient data commands such as READQ TD and WRITEQ TD return NOTOPEN for an extrapartition queue that is closed. The CICS web support returns it too. IBM APAR PH37204 describes WEB OPEN failing with NOTOPEN when a pooled TLS connection had been closed by the server.

The default action for NOTOPEN is to abend the task with AEIS. A program that codes RESP(WS-RESP) gets control back instead, because RESP implies NOHANDLE, and can test for DFHRESP(NOTOPEN). Older programs use HANDLE CONDITION NOTOPEN(paragraph). A file that is disabled raises DISABLED, a different condition with its own abend code.

Common causes

• The file was closed for a batch window, a backup or a reorganization, and a user ran the transaction before it was reopened.
• CICS tried to open the file and the open failed. A batch job holding the data set with DISP=OLD, a data set that isn't cataloged, or a region user ID without access to the data set all stop the open.
• An operator or an automation script closed the file with CEMT SET FILE(name) CLOSED and nobody reopened it.
• An extrapartition TD queue is closed, so READQ TD or WRITEQ TD against it fails.
• WEB OPEN couldn't open a connection to the remote HTTP server.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. In the transaction dump, EIBFN shows the command and EIBRSRCE the file or queue name.
2. Run CEMT INQUIRE FILE(name). It shows whether the file is open or closed, enabled, disabled or unenabled, and which data set it points to.
3. Search the CICS job log for file open and close messages for that file around the failure time. A failed open is reported there with the reason, and z/OS VSAM open messages such as IEC161I may appear in the job log too.
4. Check the batch schedule and any automation that closes CICS files. Note when the file was closed and what was due to reopen it.
5. For a TD queue, use CEMT INQUIRE TDQUEUE(name) to see whether it is open.

How to fix it

• Reopen the file once the data set is free with CEMT SET FILE(name) OPEN ENABLED.
• Fix the open failure if there was one. Cancel or wait for the job that holds the data set, catalog it, or give the CICS region user ID access to it.
• Handle NOTOPEN in the program. Test DFHRESP(NOTOPEN) after the command and show a message such as 'File temporarily unavailable, try again later' instead of abending.
• Make the batch schedule reopen every file it closes, and alert someone when a reopen fails. For files that batch and CICS both need, look at VSAM record level sharing.
• The CICS operators or systems programmers usually fix the file state. The application team adds the error handling.

What it looks like

DFHDU0203I 10/18/2026 07:02:15 CICSPRD1 A transaction dump was taken for dumpcode: AEIS, Dumpid: 1/0007.
DFHAC2206 07:02:15 CICSPRD1 Transaction PAY4 failed with abend AEIS. Updates to local recoverable resources backed out.

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