Sync point in response to EXEC CICS SYNCPOINT

Figure 1 shows the sequence of events for a successful sync point involving six conversing transactions. It illustrates the states and actions that occur when transactions issue EXEC CICS® SYNCPOINT requests. To write successful distributed applications, you do not need to understand all the data flows that occur during a distributed sync point. In this example, the programmer is concerned only with issuing EXEC CICS SYNCPOINT in response to finding a conversation in syncreceive (state 9).

1. Transaction A, which is in send state (state 2) on its conversations with transactions B and D, decides to end the distributed unit of work, and therefore issues an EXEC CICS SYNCPOINT command.
2. Transaction B sees that its half of its conversation with transaction A is in syncreceive state (state 9), so it issues an EXEC CICS SYNCPOINT command. Transaction B is responding to a request from transaction A, but it also becomes the sync point initiator for transactions C and E, and must ensure that its conversations with these transactions are in a valid state for issuing an EXEC CICS SYNCPOINT command. In this example, they are both in send state (state 2).
3. Transaction C sees that its half of its conversation with transaction B is in syncreceive state (state 9), so it issues an EXEC CICS SYNCPOINT command.
4. Transaction E sees that its half of its conversation with transaction B is in syncreceive state (state 9), so it issues an EXEC CICS SYNCPOINT command.
5. Transaction D sees that its half of its conversation with transaction A is in syncreceive state (state 9), so it issues an EXEC CICS SYNCPOINT command. Transaction D is responding to a request from transaction A, but it also becomes the sync point initiator for transaction F, and must ensure that its conversation with this transaction is in a valid state for issuing an EXEC CICS SYNCPOINT command. In this example, it is in send state (state 2).
6. Transaction F sees that its half of its conversation with transaction D is in syncreceive state (state 9), so it issues an EXEC CICS SYNCPOINT command.
7. All the transactions have now indicated, by issuing EXEC CICS SYNCPOINT commands, that they are ready to commit their changes. This process begins with transaction F, which has no agents and has responded to request commit by issuing an EXEC CICS SYNCPOINT command.
8. The distributed sync point is complete and control returns to transaction A following the EXEC CICS SYNCPOINT command.

If, however, an agent has detected an error, it can reject the sync point request with one of the following commands:

• EXEC CICS SYNCPOINT ROLLBACK (preferred response)
• EXEC CICS ISSUE ERROR
• EXEC CICS ISSUE ABEND

The EXEC CICS SYNCPOINT ROLLBACK command enables a transaction to initiate a backout operation across the whole distributed unit of work. When it is issued in response to a sync point request, it has the following effects:

1. Any changes that are made to recoverable resources by the transaction that issues the rollback request are backed out.
2. The sync point initiator is also backed out (EIBRLDBK set).