COMMIT in CICS

COMMIT in CICS is done with EXEC CICS SYNCPOINT, never with EXEC SQL COMMIT. The CICS syncpoint commits DB2 together with every other recoverable resource.

Unit of work and syncpoint

• A unit of work is all the recoverable changes a task makes between two syncpoints.
• EXEC CICS SYNCPOINT commits the unit of work: every change becomes permanent.
• EXEC CICS SYNCPOINT ROLLBACK backs the unit of work out: every change is undone.
• If the task ends without a syncpoint, CICS rolls the unit of work back automatically.

Two-phase commit with DB2

• CICS is the commit coordinator. DB2 is a participant, along with any other recoverable resources the task touched.
• Phase one (prepare): CICS asks every participant, including DB2, if it can commit.
• Phase two (commit): if all say yes, CICS tells them all to commit. If any says no, everything is backed out.
• This guarantees CICS resources (files, temporary storage queues) and DB2 tables stay in step, even if the system fails mid-commit.

Why EXEC SQL COMMIT is wrong in CICS

• EXEC SQL COMMIT commits only the DB2 changes. CICS does not know about it.
• CICS resources updated in the same unit of work would still be uncommitted, so a later rollback would leave DB2 and CICS out of sync.
• Recovery after a failure depends on CICS coordinating the commit. An SQL COMMIT bypasses that coordination.
• Rule: in a CICS program, always commit with EXEC CICS SYNCPOINT and roll back with EXEC CICS SYNCPOINT ROLLBACK.

Example

• Commit only when the SQL succeeded, otherwise roll back.
• EXEC SQL UPDATE CUSTOMER SET CITY = :WS-CITY WHERE CUSTNO = :WS-CUST-NO END-EXEC. IF SQLCODE = 0 EXEC CICS SYNCPOINT END-EXEC MOVE 'UPDATE COMPLETE' TO MSGO ELSE EXEC CICS SYNCPOINT ROLLBACK END-EXEC MOVE 'UPDATE FAILED' TO MSGO END-IF.
• The SYNCPOINT commits the DB2 update and any CICS resource updates in the same unit of work, atomically.