# AEIA: ERROR condition not handled

Source: https://wndsoftware.com/mainframe-errors/aeia

### AEIA: ERROR condition not handled

An AEIA abend means an EXEC CICS command raised the general ERROR condition and the program had no RESP option, HANDLE CONDITION or IGNORE CONDITION for it. AEIA is also the entry where IBM describes the whole group of EXEC interface condition abends, in which each code stands for one named condition that went unhandled.


#### Other names for this code

Also written as `AEIA abend`, `CICS AEIA`, `abend AEIA`, `CICS ERROR condition`, `AEIA ERROR`, `HANDLE CONDITION ERROR`, `DFHEIP abend`.


### What it means

Every EXEC CICS command ends with a response. CICS puts it in the EXEC interface block, in EIBRESP and EIBRESP2. If the response isn't NORMAL, CICS has raised a condition, such as NOTFND, DUPREC or QIDERR. What happens next depends on the program. If the command coded `RESP` or `NOHANDLE`, control goes back to the next statement. If an `IGNORE CONDITION` is in force for that condition, control also goes back. If a `HANDLE CONDITION` names a label for it, CICS jumps to that label. If none of these applies, CICS takes the default action for the condition. For most conditions that action is to abend the task.

The abend comes from the EXEC interface program, DFHEIP, and its code tells you which condition was left unhandled. AEIM is NOTFND, AEIN is DUPREC, AEYH is QIDERR, and so on. IBM documents the whole group in one place, the entry for AEIA. The entries for the other codes, for example AEX7, just name their condition and refer you to AEIA.

AEIA itself is the code for the ERROR condition. ERROR is the general condition. A `HANDLE CONDITION ERROR(label)` acts as a catch-all. It applies to any condition that has no handler of its own and whose default action would end the task. AEIA shows up less often than the codes for specific conditions, so when you see it, read the dump carefully rather than assuming a common cause.


### Common causes

- A command ended with the ERROR condition and the program had no RESP or NOHANDLE option on it, no `HANDLE CONDITION ERROR` and no `IGNORE CONDITION ERROR`.
- The program uses HANDLE CONDITION for a few conditions it expects and assumes the others can't happen.
- A HANDLE CONDITION that once named a label was later reissued for the same condition with no label. That puts the condition back to its default action, which is to abend.
- The program was converted from one style of error handling to another, and some commands were left with neither RESP checks nor an active handler.


### How to find the problem

- The terminal message `DFHAC2206` and the dump message `DFHDU0203I` give the transaction and the abend code.
- In the transaction dump, look at the EIB. EIBFN identifies the last command, EIBRESP and EIBRESP2 hold its response, and EIBRSRCE names the file, queue or program it used.
- Run the transaction under CEDF. It stops before and after each EXEC CICS command and shows the response, so you can see which command failed and with which condition.
- If the failure only happens under load, turn on CICS auxiliary trace for the transaction with CETR. The EXEC interface trace entries show each command and its response.


### How to fix it

- Code `RESP(WS-RESP) RESP2(WS-RESP2)` on each EXEC CICS command and test WS-RESP with an EVALUATE against `DFHRESP(NORMAL)` and the conditions you expect.
- Add a `WHEN OTHER` branch that records EIBFN, WS-RESP and WS-RESP2 in a log or TS queue, sends a clear message, and ends the task in a controlled way.
- In older programs that rely on HANDLE CONDITION, make sure an ERROR handler is active in every program, because handlers don't carry over to a program you LINK to.
- Then fix the problem the response points to. Each condition has its own abend code in this family, and its page covers the usual causes.


### What it looks like


```text
DFHDU0203I 10/18/2026 09:21:47 CICSPRD1 A transaction dump was taken for dumpcode: AEIA, Dumpid: 1/0031.
DFHAC2206 09:21:47 CICSPRD1 Transaction ORD1 failed with abend AEIA. Updates to local recoverable resources backed out.
```


### IBM documentation

[IBM documentation: AEIA](https://www.ibm.com/docs/en/cics-ts/6.x?topic=codes-aeia). 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

[AEIP INVREQ not handled Read →](https://wndsoftware.com/mainframe-errors/aeip)
[AEIM NOTFND not handled Read →](https://wndsoftware.com/mainframe-errors/aeim)
[AEI0 PGMIDERR not handled Read →](https://wndsoftware.com/mainframe-errors/aei0)
[AEIL DSIDERR (FILENOTFOUND) not handled Read →](https://wndsoftware.com/mainframe-errors/aeil)
[ASRA Program check in a CICS transaction Read →](https://wndsoftware.com/mainframe-errors/asra)
[AEYD Invalid output address caught by command protection Read →](https://wndsoftware.com/mainframe-errors/aeyd)

### Questions


#### Why does IBM's entry for another AExx code tell me to read AEIA?

IBM describes all the EXEC interface condition abends together under AEIA. The entry for each other code names its condition and points back there for the shared explanation.


#### Does HANDLE CONDITION ERROR stop every AEIx abend?

It catches any condition that has no handler of its own and whose default action would end the task. It has no effect on commands coded with RESP or NOHANDLE, because those return control to the program instead.


#### Is AEIA the same as AEIP?

No. AEIP is the abend for an unhandled INVREQ condition. AEIA is the code for the general ERROR condition.

[CICS transaction abends](https://wndsoftware.com/mainframe-errors/cics-abends) · [AEI9](https://wndsoftware.com/mainframe-errors/aei9) · [AEID](https://wndsoftware.com/mainframe-errors/aeid)

[← All error codes](https://wndsoftware.com/mainframe-errors/)