Consider the following example:
An order-entry transaction is designed so that, when an order for an item is entered from a terminal:
In a single CICS® system, the syncpoint causes steps 1 and 2 both to be committed.
The same result is required if the inventory file is owned by a remote system and is accessed by means of, for example, CICS function shipping. This is achieved in the following way:
During the period between the sending of the syncpoint request to the remote system and the receipt of the reply, the local system does not know whether the remote system has committed the change. This period is known as the in-doubt period, as illustrated in Figure 78.
If the intersystem session fails before the in-doubt period is reached, both sides back out in the normal way. After this period, both sides have committed their changes. If, however, the intersystem session fails during the in-doubt period, the local CICS system cannot tell whether the remote system committed or backed out its changes.
The ways in which syncpoint requests and responses are exchanged on intersystem conversations are defined in the APPC and LUTYPE6.1 architectures. CICS multiregion operation uses 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 78 through Figure 80 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 78. 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 in-doubt, but the agent is not. The local UOW that is not in-doubt is called the coordinator, because it coordinates the commitment of resources on both systems. The local UOW that is in-doubt is called the subordinate, because it must obey the decision to commit or back out taken by its coordinator.
Figure 79 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 79, Agent1 is both the coordinator of the initiator and a subordinate of Agent2.
Figure 80 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 80, the Initiator is both the coordinator of Agent1 and a subordinate of Agent2. Agent2 is the last agent.