# AEIQ: IOERR not handled Source: https://wndsoftware.com/mainframe-errors/aeiq ### AEIQ: IOERR not handled An AEIQ abend means an EXEC CICS command ran into an input/output error, CICS returned the IOERR condition, and the program didn't handle it. The command itself was valid. The data set, queue or connection behind it failed. #### Other names for this code Also written as `AEIQ abend`, `CICS AEIQ`, `abend AEIQ`, `IOERR`, `CICS IOERR`, `AEIQ IOERR`, `DFHRESP(IOERR)`. ### 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 - 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. - 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. - 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. - 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. - 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 ```text 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. ``` ### IBM documentation [IBM documentation: AEIQ](https://www.ibm.com/docs/en/cics-ts/6.x?topic=codes-aeiq). Use the documentation for your installed release. [Report a correction to WND Software](https://wndsoftware.com/contact#message). 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. ### Related codes [AEIS NOTOPEN not handled Read →](https://wndsoftware.com/mainframe-errors/aeis) [AEIU ILLOGIC not handled Read →](https://wndsoftware.com/mainframe-errors/aeiu) [AEIL DSIDERR (FILENOTFOUND) not handled Read →](https://wndsoftware.com/mainframe-errors/aeil) [AEIM NOTFND not handled Read →](https://wndsoftware.com/mainframe-errors/aeim) [AEIP INVREQ not handled Read →](https://wndsoftware.com/mainframe-errors/aeip) [S001 I/O error Read →](https://wndsoftware.com/mainframe-errors/s001) ### Questions #### Is AEIQ a program bug? Rarely. The command was valid, but the I/O under it failed. The only program fault is that it didn't handle IOERR, so a data set problem turned into a transaction dump. #### What is the difference between AEIQ and AEIU? AEIQ is IOERR, an input/output failure. AEIU is ILLOGIC, which CICS uses for VSAM errors that fit no other condition, such as an alternate index entry that points to a missing base record. #### Should the program retry after IOERR? Not for files. The data set or volume is still broken, so a retry fails the same way. For a web request a single retry on a fresh connection can be reasonable. [CICS transaction abends](https://wndsoftware.com/mainframe-errors/cics-abends) · [AEIP](https://wndsoftware.com/mainframe-errors/aeip) · [AEIR](https://wndsoftware.com/mainframe-errors/aeir) [← All error codes](https://wndsoftware.com/mainframe-errors/)