AEI2: ENDDATA not handled
An AEI2 abend means a program issued EXEC CICS RETRIEVE, there was no data left to retrieve, CICS returned the ENDDATA condition, and the program didn't handle it. Most often the transaction was started from a terminal when it expected to be started with data.
Other names for this code
Also written as AEI2 abend, CICS AEI2, abend AEI2, ENDDATA, CICS ENDDATA, AEI2 ENDDATA, RETRIEVE ENDDATA.
What it means
One CICS task can start another with EXEC CICS START, and pass it data with the FROM option. The started program picks up that data with EXEC CICS RETRIEVE. If several STARTs with data are waiting for the same transaction and terminal, the task can issue RETRIEVE several times and gets one data record each time.
ENDDATA is what RETRIEVE returns when there is nothing left. That happens when the task was started without data, when it wasn't started by START at all, or when it has already retrieved every record. In a program that loops on RETRIEVE, ENDDATA is the normal way the loop ends.
The default action for ENDDATA is to abend the task with AEI2. A program that codes RESP(WS-RESP) on the RETRIEVE gets control back instead, because RESP implies NOHANDLE, and can test for DFHRESP(ENDDATA). Older programs use HANDLE CONDITION ENDDATA(paragraph). IBM APAR PK66800 shows the typical case. Operators who mistyped a transaction code started a transaction meant only for START, and the RETRIEVE in it abended with AEI2.
Common causes
- A user typed the transaction ID at a terminal. The transaction was written to be started by another program with data, so its RETRIEVE finds nothing.
- A program loops on RETRIEVE to collect all waiting data records and doesn't treat ENDDATA as the end of the loop.
- The program that issues the START leaves out the FROM option, or a change removed it, so the started task gets no data.
- One program serves both terminal input and started requests, and it issues RETRIEVE on both paths.
How to find the problem
- The terminal message
DFHAC2206names the transaction. In the dump, EIBFN shows that the failing command was RETRIEVE. - Find out how the task was started.
EXEC CICS ASSIGN STARTCODEreturns SD for a START with data and S for a START without data. A task started from terminal input returns TD. - Check the program that issues the START. Confirm it codes FROM and LENGTH, and that it targets the right transaction ID.
- Run the transaction under CEDF to watch the RETRIEVE and its response. A trace of the starting task shows whether the START carried data.
How to fix it
- Test the start code before retrieving. If STARTCODE isn't SD, skip the RETRIEVE, or send a message such as 'This transaction can't be started from a terminal' and end cleanly.
- Code
RESP(WS-RESP)on every RETRIEVE and treatDFHRESP(ENDDATA)as 'no more data' rather than as an error. - Restrict who can start the transaction from a terminal with your security manager if users should never run it directly.
- Fix the starting program if it should pass data and doesn't.
What it looks like
DFHDU0203I 10/18/2026 14:05:51 CICSPRD1 A transaction dump was taken for dumpcode: AEI2, Dumpid: 1/0063. DFHAC2206 14:05:51 CICSPRD1 Transaction PRT2 failed with abend AEI2. Updates to local recoverable resources backed out.
IBM documentation
IBM documentation: AEI2. Use the documentation for your installed release.
Related codes
Questions
Is ENDDATA an error?
Not always. In a loop that retrieves every waiting record it simply means the loop is finished. It only becomes an abend when the program doesn't expect it.
Why does AEI2 happen when users type the transaction code?
Because a task started from a terminal has no START data. The program only works when another task starts it with FROM, so typing the code at a terminal leads straight to ENDDATA.
Can RETRIEVE fail in other ways?
Yes. It can raise LENGERR when the data is longer than the INTO area, and ENVDEFERR when it asks for an option, such as RTRANSID, that the START didn't supply.