Learn it on Mainframe Path. Do it with MainframeKit.Learn on Mainframe Path ▸
MainframeKit

AEIO

DUPKEY condition not handledCICS ABEND

The task ended because a DUPKEY condition was raised and the program had no RESP option or handler for it, so CICS used abend AEIO.

MOST LIKELY

A command raised DUPKEY and had no RESP option or NOHANDLE.

FIRST CHECK

Find the command that raised DUPKEY from the dump or trace.

TRY IT ▸

Site search

What it means

AEIx abends come from the EXEC interface program (DFHEIP). Here CICS found an unhandled DUPKEY condition: the command carried no RESP option and no HANDLE CONDITION covered it, so CICS ended the task and took a transaction dump.

The abend does not name the command that raised DUPKEY. See the DUPKEY entry: it is raised when a read through a non-unique alternate index finds more records with the same alternate key. The dump and trace show the command.

Typical causes

  • A command raised DUPKEY and had no RESP option or NOHANDLE.
  • No HANDLE CONDITION for DUPKEY was active when the command ran.

How to fix it

  1. Find the command that raised DUPKEY from the dump or trace.
  2. Look at the EIB in the dump: function code (X'1B'), EIBRCODE (X'1D'), EIBRESP (X'4C') and EIBRESP2 (X'50') help show which command it was and why.
  3. Where you can, change the program so the DUPKEY condition does not arise.
  4. Otherwise add RESP to the command and test the response, or set HANDLE CONDITION for DUPKEY, and decide what the program does then.

Example

Illustrative only; names and values are invented.

EXEC CICS READ FILE('CUSTAIX') INTO(WS-REC) RIDFLD(WS-ALTKEY)   (no RESP; illustrative alternate-index path with duplicate keys) -> task ends with AEIO