MainframeKit

DUPREC

DFHRESP(DUPREC) = 14CICS RESP CONDITION

A WRITE tried to add a record whose key is already in the file.

MOST LIKELY

The program builds a new key that is already used, for example a counter that was reset or restarted.

FIRST CHECK

Test RESP after the WRITE and treat DUPREC as 'record already exists', not as a failure of the file.

TRY IT ▸

MainframeKit assistant

What it means

RESP 14 (RESP2 150) means the key you tried to add already exists in the data set, or in a path over it that has unique keys. Nothing was written.

If the program does not test RESP for this condition, CICS ends the task abnormally.

Typical causes

  • The program builds a new key that is already used, for example a counter that was reset or restarted.
  • The same transaction ran twice for one input, so the second WRITE repeats the first.
  • An add-or-update routine always issues WRITE instead of checking whether the record exists first.
  • On a coupling facility data table using the contention model, the key exists and another task has that record read for update: CICS returns DUPREC at once instead of waiting.

How to fix it

  1. Test RESP after the WRITE and treat DUPREC as 'record already exists', not as a failure of the file.
  2. If the intent is add-or-replace, READ UPDATE first and REWRITE when found, WRITE when NOTFND.
  3. Check how the key is generated: look for a reset counter or a missing date or sequence part.
  4. Show the user a clear 'already exists' message rather than letting the task end.

Example

Illustrative only; names and values are invented.

EXEC CICS WRITE FILE('CUSTFIL') FROM(WS-CUST) RIDFLD(WS-KEY)
     RESP(WS-RESP) RESP2(WS-RESP2) END-EXEC
IF WS-RESP = DFHRESP(DUPREC)
   MOVE 'CUSTOMER ALREADY EXISTS' TO MSGO
END-IF