Synchronizing two CICS systems

This section gives examples of how to commit and back out changes to recoverable resources made by two DTP transactions connected on a conversation using MRO or sync level 2.

The examples illustrate the following scenarios:

SYNCPOINT in response to SYNCPOINT

Figure 26, Figure 27, and Figure 28 illustrate the effect of SEND, SEND INVITE, or SEND LAST preceding SYNCPOINT on an APPC mapped conversation. The figures also show the conversation state before each command and the state and EIB fields set after each command.

Figure 26. SYNCPOINT (in response to SEND followed by SYNCPOINT) on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SEND command; its conversation remains in send state.
  2. Transaction B issues a RECEIVE command; it is suspended until data is received from transaction A.
  3. Transaction A issues a SYNCPOINT command; outstanding data, and the syncpoint request, are transmitted. The transaction is suspended until the syncpoint response is received from transaction B.
  4. Transaction B's RECEIVE command completes; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  5. Transaction B issues a SYNCPOINT command; the response is transmitted, and its conversation is in receive state.
  6. Transaction A's SYNCPOINT command completes, and its conversation is in send state.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT command is issued in response to a SEND command and a SYNCPOINT command on an APPC mapped conversation.

Figure 27. SYNCPOINT (in response to SEND INVITE followed by SYNCPOINT) on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SEND INVITE command; its conversation is now in pendreceive state.
  2. Transaction B issues a RECEIVE command; it is suspended until data is received from transaction A.
  3. Transaction A issues a SYNCPOINT command; outstanding data, the INVITE flag, and the syncpoint request, are transmitted. The transaction is suspended until the syncpoint response is received from transaction B.
  4. Transaction B's RECEIVE command completes; EIBSYNC is set, and its conversation is in syncsend state.
  5. Transaction B issues a SYNCPOINT command; the response is transmitted, and its conversation is in send state.
  6. Transaction A's SYNCPOINT command completes, and its conversation is in receive state.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT command is issued in response to a SEND INVITE command and a SYNCPOINT command on an APPC mapped conversation.
Figure 28. SYNCPOINT (in response to SEND LAST followed by SYNCPOINT) on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SEND LAST command; its conversation is now in pendfree state.
  2. Transaction B issues a RECEIVE command; it is suspended until data is received from transaction A.
  3. Transaction A issues a SYNCPOINT command; outstanding data, the LAST flag, and the syncpoint request, are transmitted. The transaction is suspended until the syncpoint response is received from transaction B.
  4. Transaction B's RECEIVE command completes; EIBSYNC and EIBFREE are set, and its conversation is in syncfree state.
  5. Transaction B issues a SYNCPOINT command; the response is transmitted, and its conversation is in free state.
  6. Transaction A's SYNCPOINT command completes, and its conversation is in free state.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT command is issued in response to a SEND INVITE command and a SYNCPOINT command on an APPC mapped conversation.

SYNCPOINT in response to ISSUE PREPARE

Figure 29 illustrates a SYNCPOINT command being used in response to ISSUE PREPARE on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command.

Note that it is also possible to use an ISSUE PREPARE command in pendreceive state (state 3) and pendfree state (state 4).

Note also that, although the ISSUE PREPARE command in Figure 29 returns with the conversation in syncsend state (state 10), the only commands available for use on that conversation are SYNCPOINT and SYNCPOINT ROLLBACK. All other commands abend ATCV.

Figure 29. SYNCPOINT in response to ISSUE PREPARE on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues an ISSUE PREPARE command; the prepare request is transmitted, and the transaction is suspended until a syncpoint request is received from transaction B
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues a SYNCPOINT command; the syncpoint request is transmitted, and the transaction is suspended until the syncpoint response is received from transaction A.
  4. Transaction A's ISSUE PREPARE command completes; its conversation is in syncsend state.
  5. Transaction A issues a SYNCPOINT command; the response is transmitted, and its conversation is in send state.
  6. Transaction B's SYNCPOINT command completes, and its conversation is in receive state.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT command is issued in response to a ISSUE PREPARE command on an APPC mapped conversation.

SYNCPOINT ROLLBACK in response to SYNCPOINT ROLLBACK

Figure 30 illustrates a SYNCPOINT ROLLBACK command being used in response to SYNCPOINT ROLLBACK on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command.

Figure 30. SYNCPOINT ROLLBACK in response to SYNCPOINT ROLLBACK on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SYNCPOINT ROLLBACK command; the rollback request is transmitted, and the transaction is suspended until a rollback response is received from transaction B
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBERR and EIBSYNRB are set, and its conversation is in rollback state.
  3. Transaction B issues a SYNCPOINT ROLLBACK command; the rollback response is transmitted; transaction B's conversation is restored to the state it was in at the start of the unit of work.
  4. Transaction A's SYNCPOINT ROLLBACK command completes; its conversation is restored to the state it was in at the start of the unit of work.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT ROLLBACK command is issued in response to a SYNCPOINT ROLLBACK command on an APPC mapped conversation.

SYNCPOINT ROLLBACK in response to SYNCPOINT

Figure 31 illustrates a SYNCPOINT ROLLBACK command being used in response to SYNCPOINT on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command.

Figure 31. SYNCPOINT ROLLBACK in response to SYNCPOINT on an APPC mapped conversation. In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.
  1. Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues a SYNCPOINT ROLLBACK command; the rollback response is transmitted; transaction B's conversation is restored to the state it was in at the start of the unit of work.
  4. Transaction A's SYNCPOINT command completes; EIBRLDBK is set; transaction A's conversation is restored to the state it was in at the start of the unit of work.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT ROLLBACK command is issued in response to a SYNCPOINT command on an APPC mapped conversation.

SYNCPOINT ROLLBACK in response to ISSUE PREPARE

Figure 32 illustrates a SYNCPOINT ROLLBACK command being used in response to ISSUE PREPARE on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command.

Figure 32. SYNCPOINT ROLLBACK in response to ISSUE PREPARE on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues an ISSUE PREPARE command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues a SYNCPOINT ROLLBACK command; the rollback response is transmitted; transaction B's conversation is restored to the state it was in at the start of the unit of work.
  4. Transaction A's ISSUE PREPARE command completes; EIBERR and EIBRLDBK are set; transaction A's conversation is restored to the state it was in at the start of the unit of work.
 This figure shows the state changes, and the EIB flags that are set, when a SYNCPOINT ROLLBACK command is issued in response to a ISSUE PREPARE command on an APPC mapped conversation.

ISSUE ERROR in response to SYNCPOINT

Figure 33 illustrates an ISSUE ERROR command being used in response to SYNCPOINT on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command. You can also send ISSUE ERROR before receiving SYNCPOINT; but this is not shown, because the results are the same.

It is pointless to use ISSUE ERROR as a response to SYNCPOINT, because this causes the syncpoint initiator to discard all data transmitted with the ISSUE ERROR by the syncpoint agent. To safeguard integrity, the syncpoint agent has to issue a SYNCPOINT ROLLBACK command.

Note that if transaction A were running on a CICS® release earlier than 3.2, the results would be different. (See the Intercommunication Guide for the relevant release.)

Figure 33. ISSUE ERROR in response to SYNCPOINT on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues an ISSUE ERROR command; its conversation is in send state.
  4. Transaction B issues a SEND INVITE WAIT command; the error indication and the INVITE flag are transmitted to transaction A; transaction B's conversation is in receive state.
  5. On behalf of transaction A, CICS sends a rollback request to transaction B.
  6. Transaction B issues a RECEIVE command which returns control immediately; EIBERR and EIBSYNRB are set, and its conversation is in rollback state.
  7. Transaction B issues a SYNCPOINT ROLLBACK command; the rollback response is transmitted; transaction B's conversation is restored to the state it was in at the start of the unit of work.
  8. Transaction A's SYNCPOINT command completes; EIBRLDBK is set; transaction A's conversation is restored to the state it was in at the start of the unit of work.
 This figure shows the state changes, and the EIB flags that are set, when an ISSUE ERROR command is issued in response to a SYNCPOINT command on an APPC mapped conversation.

ISSUE ERROR in response to ISSUE PREPARE

Figure 34 illustrates an ISSUE ERROR command being used in response to ISSUE PREPARE on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command. You can also send ISSUE ERROR before receiving ISSUE PREPARE; but this is not shown, because the results are the same.

Figure 34. ISSUE ERROR in response to ISSUE PREPARE on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues an ISSUE PREPARE command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues an ISSUE ERROR command; its conversation is in send state.
  4. Transaction B issues a WAIT command; the error indication is transmitted to transaction A; transaction B's conversation is in send state.
  5. Transaction A's ISSUE PREPARE command completes; EIBERR is set; transaction A's conversation is in receive state.
 This figure shows the state changes, and the EIB flags that are set, when an ISSUE ERROR command is issued in response to an ISSUE PREPARE command on an APPC mapped conversation.

ISSUE ABEND in response to SYNCPOINT

Figure 35 illustrates an ISSUE ABEND command being used in response to SYNCPOINT on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command. You can also send ISSUE ABEND before receiving SYNCPOINT; but this is not shown, because the results are the same.

Figure 35. ISSUE ABEND in response to SYNCPOINT on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues an ISSUE ABEND command; theabend indication is transmitted; transaction B's conversation is in free state.
  4. Transaction A abends with code ASP3.
  5. Transaction B issues a FREE command to free its conversation with transaction A.
  6. Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources remain consistent with transaction A's resources.
 This figure shows the state changes, and the EIB flags that are set, when an ISSUE ABEND command is issued in response to a SYNCPOINT command on an APPC mapped conversation.

ISSUE ABEND in response to ISSUE PREPARE

Figure 36 illustrates an ISSUE ABEND command being used in response to ISSUE PREPARE on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command. You can also send ISSUE ABEND before receiving ISSUE PREPARE; but this is not shown, because the results are the same.

Figure 36. ISSUE ABEND in response to ISSUE PREPARE on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues an ISSUE PREPARE command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues an ISSUE ABEND command; theabend indication is transmitted; transaction B's conversation is in free state.
  4. Transaction A's ISSUE PREPARE command completes; EIBERR and EIBFREE are set; transaction A's conversation is in free state.

    From this point, the two transactions are independent of one another.

  5. Transaction A issues a FREE command to free its conversation with transaction A.
  6. Transaction A issues a SYNCPOINT ROLLBACK command in order that its resources remain consistent with transaction A's resources.
  7. Transaction B issues a FREE command to free its conversation with transaction A.
  8. Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources remain consistent with transaction A's resources.
 This figure shows the state changes, and the EIB flags that are set, when an ISSUE ABEND command is issued in response to an ISSUE PREPARE command on an APPC mapped conversation.

Session failure in response to SYNCPOINT

Figure 37 and Figure 38 illustrate what happens if the session fails before or after a SYNCPOINT command issued in response to SYNCPOINT on an APPC mapped conversation. The figures also show the conversation state before each command and the state and EIB fields set after each command.

Figure 37. Session failure before SYNCPOINT in response to SYNCPOINT on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. The session between transaction A and transaction B fails.

    From this point , the two transactions are independent of one another.

  4. Transaction B issues a SYNCPOINT command; its conversation is freed, and a NOTALLOC condiition is raised for any further commands that attempt to use the conversation.
  5. Transaction A abends with code ASP3.
 This figure shows the state changes, and the EIB flags that are set, as the result of a session failure before a SYNCPOINT command is issued in response to a SYNCPOINT command on an APPC mapped conversation.

Figure 38. Session failure after SYNCPOINT in response to SYNCPOINT on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. Transaction B issues a SYNCPOINT command; the response is transmitted, and its conversation is in receive state.
  4. The session between transaction A and transaction B fails.

    From this point , the two transactions are independent of one another.

  5. Transaction A abends with code ASP3.
  6. Transaction B issues a RECEIVE command which returns control immediately; EIBERR and EIBFREE are set, and its conversation is in free state.
  7. Transaction B issues a FREE command to free its conversation with transaction A.
  8. Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources remain consistent with transaction A's resources.
 This figure shows the state changes, and the EIB flags that are set, as the result of a session failure after a SYNCPOINT command is issued in response to a SYNCPOINT command on an APPC mapped conversation

Session failure in response to ISSUE PREPARE

Figure 39 illustrates what happens if the session fails after ISSUE PREPARE is received by transaction B and before the SYNCPOINT response is received by transaction A on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command.

Figure 39. Session failure during SYNCPOINT in response to ISSUE PREPARE on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues an ISSUE PREPARE command; the syncpoint request is transmitted, and the transaction is suspended until a response is received from transaction B.
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
  3. The session between transaction A and transaction B fails.

    From this point , the two transactions are independent of one another.

  4. Transaction A abends with code ASP1.
  5. Transaction B issues a SYNCPOINT command; its conversation is in receive state.
  6. Transaction B issues a RECEIVE command which returns control immediately; EIBERR and EIBFREE are set, and its conversation is in free state.
  7. Transaction B issues a FREE command to free its conversation with transaction A.
  8. Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources remain consistent with transaction A's resources.
 This figure shows the state changes, and the EIB flags that are set, as the result of a session failure when a SYNCPOINT command is issued in response to an ISSUE PREPARE command on an APPC mapped conversation

Session failure in response to SYNCPOINT ROLLBACK

Figure 40 illustrates what happens if the session fails after SYNCPOINT ROLLBACK is received and before the response is issued on an APPC mapped conversation. The figure also shows the conversation state before each command and the state and EIB fields set after each command.

Figure 40. Session failure during SYNCPOINT ROLLBACK in response to SYNCPOINT ROLLBACK on an APPC mapped conversation.

In this figure, transaction A is communicating with transaction B using an APPC mapped conversation. Initially, transaction A's conversation with B is in send state, and transaction B's conversation with A is in receive state.

  1. Transaction A issues a SYNCPOINT ROLLBACK command; the rollback request is transmitted, and the transaction is suspended until a rollback response is received from transaction B
  2. Transaction B issues a RECEIVE command which returns control immediately; EIBERR and EIBSYNRB are set, and its conversation is in rollback state.
  3. The session between transaction A and transaction B fails.

    From this point , the two transactions are independent of one another.

  4. Transaction B issues a SYNCPOINT ROLLBACK command; its conversation is in free state.
  5. Transaction A's SYNCPOINT ROLLBACK command completes; its conversation is in free state.
 This figure shows the state changes, and the EIB flags that are set, as the result of a session failure when a SYNCPOINT ROLLBACK command is issued in response to a SYNCPOINT ROLLBACK command on an APPC mapped conversation
[[ Contents Previous Page | Next Page Index ]]