Syncpoint flows

The ways in which syncpoint requests and responses are exchanged on intersystem conversations are defined in the APPC and LUTYPE6.1 architectures. CICS MRO and IPIC use the APPC recovery protocols. Although the formats of syncpoint flows for APPC and LUTYPE6.1 are different, the concepts of syncpoint exchanges are similar.

In CICS, the flows involved in syncpoint exchanges are generated automatically in response to explicit or implicit SYNCPOINT commands issued by a transaction. However, a basic understanding of the flows that are involved can help you in the design of your application and give you an appreciation of the consequences of session or system failure during the syncpoint activity. For more information about these flows, see the CICS Distributed Transaction Programming Guide.

Figures Figure 1 through Figure 3 show some examples of syncpoint flows. In the figures, the numbers in brackets, for example, (1), show the sequence of the actions in each flow.

A CICS task may contain one or more UOWs. A local UOW that initiates syncpoint activity—by, for example, issuing an EXEC CICS SYNCPOINT or an EXEC CICS RETURN command—is called an initiator. A local UOW that receives syncpoint requests from an initiator is called an agent. The simplest case is shown in Figure 1. There is a single conversation between an initiator and an agent. At the start of the syncpoint activity, the initiator sends a commit request to the agent. The agent commits its changes and responds with committed. The initiator then commits its changes, and the unit of work is complete. However, the agent retains recovery information about the UOW until its partner tells it (by means of a “forget” flow) that the information can be discarded.

Between the commit flow and the committed flow, the initiator is indoubt, but the agent is not. The local UOW that is not indoubt is called the coordinator, because it coordinates the commitment of resources on both systems. The local UOW that is indoubt is called the subordinate, because it must obey the decision to commit or back out taken by its coordinator.

Figure 1. Syncpointing flows—unique session. In this distributed UOW, there is one coordinator and one subordinate. The coordinator is not indoubt.

Figure 2 shows a more complex example. Here, the agent UOW (Agent1) has a conversation with a third local UOW (Agent2). Agent1 initiates syncpoint activity on this latter conversation before it responds to the initiator. Agent2 commits first, then Agent1, and finally the initiator. Note that, in Figure 2, Agent1 is both the coordinator of the initiator and a subordinate of Agent2.

Figure 2. Syncpointing flows—chained sessions. In this distributed UOW, Agent1 is both the coordinator of the initiator, and a subordinate of Agent2.

Figure 3 shows a more general case, in which the initiator UOW has more than one (directly-connected) agent. It must inform each of its agents that a syncpoint is being taken. It does this by sending a “prepare to commit” request to all of its agents except the last. The last agent is the agent that is not told to prepare to commit.

Each agent that receives a “prepare” request responds with a “commit” request. When all such “prepare” requests have been sent and all the “commit” responses received, the initiator sends a “commit” request to its last agent. When this responds with a “committed” indication, the initiator then sends “committed” requests to all the other agents.

Note that, in Figure 3, the Initiator is both the coordinator of Agent1 and a subordinate of Agent2. Agent2 is the last agent.

Figure 3. Syncpointing flows—multiple sessions. In this distributed UOW, the Initiator is both the coordinator of Agent1, and a subordinate of Agent2. Agent2 is the last agent, and is therefore not told to prepare to commit.