Preventing duplicate writes during CICS transaction retries

Question

In a COBOL application running under CICS, maintaining data integrity during transaction retries is critical. While the use of sync-points and the EXEC CICS SYNCPOINT command ensures that a Logical Unit of Work (LUW) is processed atomically, the system does not natively track whether a specific business event has already been persisted if the transaction is restarted from an external trigger.

When a transaction fails after a partial write but before a final commit, the transaction manager handles the rollback. However, if the retry logic is initiated by an external system or a user, there is a risk of duplicating records if the previous attempt partially succeeded in a way that bypassed the sync-point or if the retry occurs after a successful commit but before the confirmation is received.

What are the established patterns for implementing idempotency within COBOL to ensure that retried transactions do not create duplicate entries in the database? Which mechanism is more reliable for verifying record existence before a write operation in high-volume CICS environments?

Tasadduq Burney · Answer

Answer
Confirmed fact: CICS guarantees atomic rollback of any work performed before a SYNCPOINT when a transaction abends, so partial writes are undone.
Likely explanation
If an external trigger retries a transaction after it has already committed, the application has no native record of whether the business event was persisted, so a re‑issued INSERT can create a duplicate.
Established idempotency pattern

Generate a durable, globally unique identifier for the business event (e.g., CICS LUWID, a timestamp‑based key, or the external business key).
Within the same LUW, first write that identifier to a control table or VSAM KSDS that has a unique index.
If the insert of the identifier fails with a duplicate‑key condition, treat the event as already processed and skip the business write.
If the identifier insert succeeds, proceed with the actual business INSERT/UPDATE.
Issue EXEC CICS SYNCPOINT only after both the identifier and the business writes have succeeded.

More reliable verification mechanism for high‑volume CICS
Use a VSAM key‑sequenced data set (KSDS) or a DB2 table with a unique index on the identifier and perform a single‑row SELECT … FOR UPDATE (or the equivalent lock‑then‑read) inside the same LUW. This test‑and‑set operation is atomic under CICS sync‑point control, eliminating the race window where two concurrent retries could both see “not exists” and insert duplicates.
EXEC CICS
   WRITE FILE('CTLFILE')
   FROM(WS-ID)
   END-EXEC.
IF EIBRESP = DFHRESP(NORMAL)
   *> proceed with business write
ELSE IF EIBRESP = DFHRESP(DUPREC)
   *> skip business write, event already processed
END-IF.

Preventing duplicate writes during CICS transaction retries

1 answer

Answer

Likely explanation

Established idempotency pattern

More reliable verification mechanism for high‑volume CICS

Your perspective belongs here.

0 question comments