Synchronizing three or more CICS systems

This section gives examples of how to commit and back out recoverable resources affected by three or more DTP transactions connected on conversations at sync level 2.

SYNCPOINT in response to SYNCPOINT

Figure 41 shows the sequence of events for a successful syncpoint involving six conversing transactions:

Transaction A
Transaction B
Transaction C
Transaction D
Transaction E
Transaction F

It illustrates the states and actions that occur when transactions issue SYNCPOINT requests. To write successful distributed applications you do not need to understand all the data flows that take place during a distributed syncpoint. In this example, the programmer is concerned only with issuing SYNCPOINT in response to finding a conversation in syncreceive state (state 9).

Figure 41. A distributed syncpoint with all partners running on CICS Transaction Server for z/OS, Version 3 Release 1
 This figure shows the interactions and state changes during a syncpoint in a distributed transaction.
  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 a SYNCPOINT command.
  2. Transaction B sees that its half of its conversation with transaction A is in syncreceive state (state 9), so it issues a SYNCPOINT command. Transaction B is responding to a request from transaction A, but it also becomes the syncpoint initiator for transactions C and E, and must ensure that its conversations with these transactions are in a valid state for issuing a 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 a SYNCPOINT command.
  4. Transaction E sees that its half of its conversation with transaction B is in syncreceive state (state 9), so it issues a SYNCPOINT command.
  5. Transaction D sees that its half of its conversation with transaction A is in syncreceive state (state 9), so it issues a SYNCPOINT command. Transaction D is responding to a request from transaction A, but it also becomes the syncpoint initiator for transaction F, and must ensure that its conversation with this transaction is in a valid state for issuing a 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 a SYNCPOINT command.
  7. All the transactions have now indicated, by issuing 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 a SYNCPOINT command.
  8. The distributed syncpoint is complete and control returns to transaction A following the SYNCPOINT command.

The previous discussion of the SYNCPOINT command assumed that all the agent transactions were ready to take a syncpoint by issuing SYNCPOINT when their conversation entered syncreceive state (state 9).

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

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

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

This causes the syncpoint initiator to initiate a backout operation across the distributed unit of work.

SYNCPOINT ROLLBACK in response to SYNCPOINT

Figure 42 shows the sequence of events for a syncpoint involving six conversing transactions, when one of the agents determines that the distributed transaction should be backed out. The topology, and initial states are the same as in Figure 41:

Transaction A
Transaction B
Transaction C
Transaction D
Transaction E
Transaction F

Figure 42. Rollback during distributed syncpointing
 This figure shows the interactions and state changes during a syncpoint in a distributed transaction, when one of the agents determines that the transaction should be backed out.

As in Figure 41, transaction A (while in send state, state 2) issues the SYNCPOINT command, and CICS® initiates a chain of events. Here, however, transaction E has detected an error that makes it unable to commit, and it issues SYNCPOINT ROLLBACK when it detects that the conversation on its principal facility is in syncreceive state (state 9, EIBSYNC is also set). This causes any changes that transaction E has made to be backed out, and initiates a distributed rollback.

Transactions B, C and A are rolled back (EIBRLDBK set). Transaction D senses that the conversation on its principal facility is in rollback state (state 13, EIBSYNRB is also set), and issues a SYNCPOINT ROLLBACK command. Transaction F too senses that the conversation on its principal facility is in rollback state, and issues a SYNCPOINT ROLLBACK command. The distributed rollback is now complete.

Session failure and the indoubt period

During the period between the sending of the syncpoint request to the partner system and the receipt of the reply, the local system does not know whether the partner system has committed the change. This is known as the indoubt period. If the intersystem session fails during this period, the local CICS system cannot tell whether the partner system has committed or backed out its resource changes.

This situation could occur for situations other than DTP and is discussed in the "Recovery and restart" section of the CICS Intercommunication Guide.

[[ Contents Previous Page | Next Page Index ]]