AEIN: DUPREC not handled

What it means

DUPREC is the file control condition for a duplicate key. It comes up in two ways. A WRITE that adds a record raises it when a record with that key is already in the data set. The same is true when the WRITE goes through a path whose alternate index was defined with UNIQUEKEY. A REWRITE raises it when the data set's upgrade set includes a unique-key alternate index and the updated record carries an alternate key that is already in that index. In both cases EIBRESP2 is 150.

Coupling facility data tables that use the contention model add one more case. There a WRITE gets DUPREC even when the existing record has only been read for update by another task. Other file types make the WRITE wait for the lock instead.

The default action for DUPREC is to abend the task with AEIN. A program that codes RESP(WS-RESP) gets control back and can test for DFHRESP(DUPREC). Older programs use HANDLE CONDITION DUPREC(paragraph).

Common causes

• The program assumes every WRITE is for a new key. A user enters an order or customer number that is already on file.
• The same request is sent twice. A user presses Enter again after a slow response, or a client retries after a timeout even though the first WRITE had already completed.
• Key generation is broken. A counter in a control record wasn't updated, or two tasks read the same next number before either one saved the new value.
• A restart reprocesses input that was already applied, so it adds records that are already there.
• A REWRITE changes a field that is the key of a unique alternate index, such as an email address or tax ID, to a value another record already holds.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. In the dump, EIBFN shows whether the command was a WRITE or a REWRITE and EIBRSRCE names the file. EIBRESP2 is 150.
2. Run the transaction under CEDF and look at the RIDFLD key on the WRITE. Then check the data set for that key with File Manager or an IDCAMS PRINT using FROMKEY and TOKEY.
3. For a REWRITE, find the alternate indexes in the upgrade set. An IDCAMS LISTCAT of the AIX shows whether it is defined with unique keys and whether it is an upgrade AIX.
4. Run CEMT INQUIRE FILE(name) to see which data set the CICS file points to in this region.

How to fix it

• Handle DUPREC. Test DFHRESP(DUPREC) after the WRITE and send the user a clear message, such as 'Order number already exists'.
• If the program should add or update, read the record for update first. Use REWRITE when it exists and WRITE when the READ returns NOTFND.
• Generate keys safely. Read the control record with UPDATE so only one task holds it at a time, or use the CICS named counter server with EXEC CICS GET COUNTER.
• Make retries and restarts safe to repeat. Check whether the record already exists before adding it again.
• For a unique alternate index, check the new value before the REWRITE and tell the user it's already in use.

What it looks like

DFHDU0203I 10/18/2026 11:05:12 CICSPRD1 A transaction dump was taken for dumpcode: AEIN, Dumpid: 1/0044.
DFHAC2206 11:05:12 CICSPRD1 Transaction ORD2 failed with abend AEIN. 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.