What really flows between APPC systems

This section describes the commit protocols that flow between APPC systems during a syncpoint. The arrows in the diagrams show the syncpoint flows in more detail than in the figures earlier in this section.

First, consider a simple distributed process involving only one conversation, as in Figure 43. Here is what happens:

  1. The syncpoint initiator sends a "commit" request to the syncpoint agent.
  2. The syncpoint agent commits all changes it made to recoverable resources, and responds with "committed".
  3. The syncpoint initiator then commits its changes, and the UOW is complete.

Figure 43. Syncpoint flows in a single conversation
 This figure illustrates the syncpoint flows over a single conversation between two systems. The flows are described in the text.

When the syncpoint agent has a conversation with a third transaction, Figure 44 shows the flows that occur. Here is what happens:

  1. The syncpoint initiator sends a "commit" request to its agent.
  2. The agent becomes the initiator on the conversation to its agent, and sends a "commit" request.
  3. The second agent commits first and responds with "committed".
  4. The first agent commits and sends "committed" to the initiator.
  5. The initiator commits.
Figure 44. Syncpoint flows in concurrent conversations
 This figure illustrates the syncpoint flows between three systems, where the syncpoint initiator has one agent. The flows are described in the text.

When the syncpoint initiator has two concurrent conversations, the flows involved are shown in Figure 45. Here is what happens:

  1. The syncpoint initiator sends a "prepare" request to all its agents except one.
  2. The agent receiving "prepare" responds by sending a "commit" request to the initiator.
  3. When all the "prepare" requests have been sent, and the "commit" requests received, the initiator sends a "commit" request to its last agent.
  4. The initiator receives "committed" from the last agent.
  5. The initiator sends "committed" to the remaining agents.
  6. The agents respond "forget" to indicate that they do not need to be resynchronized.
Figure 45. Syncpoint flows in concurrent conversations with one initiator. The initiator uses only SYNCPOINT.
 This figure illustrates the syncpoint flows between three systems, where the syncpoint initiator has two agents. The flows are described in the text.

If the syncpoint initiator decides to prepare the conversation with system 2 explicitly before issuing a syncpoint, the flows involved are shown in Figure 46. In this case, the application program in system 1 issues an ISSUE PREPARE command, followed by SYNCPOINT command, rather than just a SYNCPOINT command; however, the flows across the links are exactly the same as those in the previous example. Using the ISSUE PREPARE command gives the application the opportunity to "change its mind" and rollback, depending on the response to ISSUE PREPARE.

Figure 46. Syncpoint flows in concurrent conversations with one initiator. The initiator uses ISSUE PREPARE before SYNCPOINT.
 This figure illustrates the syncpoint flows between three systems, where the syncpoint initiator has two agents. In this example, the syncpoint initiator issues ISSUE PREPARE against one of its agents. The flows are described in the text.

For further information on the flows in a distributed process, see the SNA Reference: Peer Protocols book.

[[ Contents Previous Page | Next Page Index ]]