CICS abend

AEI0: PGMIDERR not handled

An AEI0 abend means a CICS program asked for another program with LINK, XCTL, LOAD or RELEASE, CICS returned the PGMIDERR condition because it couldn't provide that program, and the calling program didn't handle the condition.

Also written as AEI0 abend, CICS AEI0, abend AEI0, PGMIDERR, AEI0 PGMIDERR, CICS PGMIDERR.

What it means

Every EXEC CICS command ends with a condition. NORMAL means it worked. Anything else is an exception condition with its own name, such as PGMIDERR or NOTFND. PGMIDERR means the program asked for another program by name, and CICS couldn't provide it. The target isn't defined, is disabled, or can't be loaded.

A program can deal with exception conditions in two ways. The modern way is to code RESP(WS-RESP) on the command, and usually RESP2(WS-RESP2) too. CICS then doesn't abend for the condition. It puts a value in WS-RESP for the program to test against DFHRESP(PGMIDERR), and a number in WS-RESP2 that narrows down the reason. The older way is EXEC CICS HANDLE CONDITION PGMIDERR(paragraph), which tells CICS to jump to that paragraph when the condition occurs. If the program does neither, CICS takes the default action for PGMIDERR, which is to abend the task with AEI0.

The last character is the digit zero. Don't mix it up with AEIO, which ends in the letter O. That is a different abend, for an unhandled DUPKEY condition on a file command.

Common causes

  • The target program isn't deployed to this region, or its PROGRAM definition isn't installed here and program autoinstall is off.
  • The program name is built at run time and is wrong. A misspelled name, lower case letters, or leftover characters from an earlier value in the same field all give PGMIDERR.
  • The target program is defined but disabled.
  • A PROGRAM definition exists but the load module is missing from the libraries, or can't be loaded.

How to find the problem

  1. The terminal message DFHAC2206 names the transaction. In the transaction dump, the EIB shows the failing command, and EIBRSRCE holds the name of the program it tried to reach.
  2. Run the transaction under CEDF. It stops on the LINK or XCTL, shows the program name being requested, and then shows the PGMIDERR response. This is often the quickest way to spot a wrong or badly padded name.
  3. Check the target with CEMT INQUIRE PROGRAM(name). It shows whether the program is defined, enabled and loaded. If CEMT can't find it at all, the definition is missing from this region.
  4. If the program codes RESP2, log or display its value. It tells you which of the reasons applies. The values are listed with each command in the CICS application programming reference for your release.

How to fix it

  • Deploy or define the missing program, or enable it, and use CEMT SET PROGRAM(name) NEWCOPY or PHASEIN after replacing a load module.
  • Correct the program name, or the code that builds it.
  • Check the response on every LINK and XCTL. Code RESP(WS-RESP) RESP2(WS-RESP2) on the command and test IF WS-RESP NOT = DFHRESP(NORMAL). When it fails, write the program name and both values to a log, and show the user a clear message instead of an abend.
  • Missing or disabled programs are usually fixed by the CICS systems programmers or the change team. Wrong names and missing RESP checks are for the application team.

What it looks like

DFHDU0203I 10/12/2026 13:21:50 CICSPRD1 A transaction dump was taken for dumpcode: AEI0, Dumpid: 1/0071.
DFHAC2206 13:21:50 CICSPRD1 Transaction ORD1 failed with abend AEI0. Updates to local recoverable resources backed out.

Questions

What is the difference between AEI0 and APCT?

AEI0 comes from a running program that asked for another program and didn't handle PGMIDERR. APCT means CICS couldn't get a program it needed itself, usually the first program of the transaction.

Should I use RESP or HANDLE CONDITION?

RESP is the usual choice in new code. The check sits right after the command, so the flow is easy to follow. HANDLE CONDITION still works and appears in a lot of older programs.

Is it AEI0 or AEIO?

AEI0 ends in the digit zero and means PGMIDERR wasn't handled. AEIO, ending in the letter O, is a separate abend for an unhandled DUPKEY condition, so check which one your message shows.