AEIQ: IOERR not handled

What it means

IOERR is the condition CICS raises when the I/O under a command fails and no more specific condition fits. The program asked for something reasonable. The read or write that CICS started on its behalf went wrong.

Many command groups can return it. File control commands such as READ, WRITE, REWRITE, DELETE and the browse commands return IOERR when VSAM or BDAM reports an I/O error on the data set. Transient data commands return it for problems on an extrapartition queue, and temporary storage commands can return it when auxiliary storage fails. The CICS web commands use it too. IBM APAR PH37204 describes WEB CONVERSE failing with IOERR after a remote server closed a pooled TLS connection.

Every condition has a default action. For IOERR the default is to abend the task with AEIQ. A program that codes RESP(WS-RESP) on the command gets control back with the condition in WS-RESP, because RESP implies NOHANDLE. It can then test for DFHRESP(IOERR). Older programs use HANDLE CONDITION IOERR(paragraph) instead. Handling the condition doesn't repair anything. It lets the program log the failure, back out its work and tell the user, instead of ending with a dump.

Common causes

• A damaged VSAM data set or a failing volume. A media error, or a data set left in a bad state by a failed batch job, makes the physical read or write fail.
• A problem with the data set behind an extrapartition transient data queue. IBM APAR PH05070 describes SET TDQUEUE CLOSED returning IOERR with RESP2 14 when the queue's PDS directory was full.
• A broken network connection during a web request. WEB SEND, WEB RECEIVE and WEB CONVERSE can return IOERR when the conversation with the HTTP server fails part way through.
• A failure on the auxiliary temporary storage data set (DFHTEMP) when the TS queue lives in auxiliary storage.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. In the transaction dump, EIBFN shows the failing command, EIBRSRCE the file or queue name, and EIBRESP2 the reason code.
2. Read the CICS job log (MSGUSR and the console) for the same minute. File control reports a VSAM I/O failure with its own DFHFC message, which names the file and data set and gives the VSAM codes.
3. Check the z/OS system log for hardware or I/O messages against the volume. Run IDCAMS EXAMINE against a KSDS to see whether its index or data component is damaged.
4. For a TD queue, CEMT INQUIRE TDQUEUE(name) shows the queue and its status. For a web request, look at the TCP/IP and AT-TLS messages for the same time.
5. If the failure repeats, run the transaction under CEDF to see the exact command and the IOERR response.

How to fix it

• Repair the resource first. Close the file in CICS, restore or rebuild the data set from a backup plus forward recovery logs, or move it off a failing volume, then reopen it with CEMT SET FILE(name) OPEN ENABLED.
• Code RESP(WS-RESP) RESP2(WS-RESP2) on file, queue and web commands. Treat IOERR as a hard failure. Log the resource name, the RESP2 value and the key, roll back with SYNCPOINT ROLLBACK if the task has made updates, and show the user a short message.
• For web requests, retry once on a new connection. IBM fixed the pooled AT-TLS case in PH37204 and gave SOCKETCLOSE(0) on the URIMAP as a local workaround.
• The storage or systems team usually fixes the data set or volume. The application team owns the error handling.

What it looks like

DFHDU0203I 10/18/2026 09:12:40 CICSPRD1 A transaction dump was taken for dumpcode: AEIQ, Dumpid: 1/0042.
DFHAC2206 09:12:40 CICSPRD1 Transaction ORD1 failed with abend AEIQ. 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.