AEIA: ERROR condition not handled

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

1. The terminal message DFHAC2206 and the dump message DFHDU0203I give the transaction and the abend code.
2. 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.
3. 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.
4. 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

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.

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.