Syncpoint

A syncpoint is the moment CICS commits a unit of work. Everything updated since the last syncpoint becomes permanent, and the locks are released. It is the most important command in CICS recovery programming.

What EXEC CICS SYNCPOINT does

• It commits all changes made to recoverable resources since the start of the current unit of work.
• CICS uses the two-phase commit protocol to coordinate the commit across resource managers - VSAM, DB2, MQ and remote CICS regions.
• After a successful syncpoint, the changes are permanent and the unit of work ends; a new one begins immediately.
• Always code the RESP option so your program knows whether the commit actually succeeded.

Implicit syncpoints

• CICS takes an automatic syncpoint when a task ends normally - at EXEC CICS RETURN, XCTL to the last program, or abnormal end handling.
• There is no implicit syncpoint at a terminal read in a conversational task - the unit of work stays open across the read.
• Because of this, a program that updates and then waits for the user holds its locks for the whole think time - avoid this pattern.

SYNCPOINT ROLLBACK

• SYNCPOINT ROLLBACK backs out the current unit of work instead of committing it, then starts a fresh unit of work.
• Use it when validation fails after updates, or when a called routine reports an error the program cannot fix.
• Example - commit with error checking and a rollback path:-
  4000-COMMIT-WORK.
  EXEC CICS
  SYNCPOINT
  RESP(RESP-CODE)
  END-EXEC.
  IF RESP-CODE NOT = DFHRESP(NORMAL)
  PERFORM 9000-HANDLE-SYNCFAIL
  END-IF.
  
  9000-HANDLE-SYNCFAIL.
  EXEC CICS
  SYNCPOINT ROLLBACK
  END-EXEC.
  MOVE 'Commit failed - changes were backed out.' TO MSGO.
  EXEC CICS RETURN END-EXEC.
• Never issue a syncpoint in the middle of a browse or while holding a READ UPDATE without REWRITE - rethink the logic first.