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:
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.
- Transaction A issues a SEND command; its conversation remains in send state.
- Transaction B issues a RECEIVE command; it is suspended until data is
received from transaction A.
- 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.
- Transaction B's RECEIVE command completes; EIBSYNC and EIBRECV are set,
and its conversation is in syncreceive state.
- Transaction B issues a SYNCPOINT command; the response is transmitted,
and its conversation is in receive state.
- Transaction A's SYNCPOINT command completes, and its conversation is
in send state.
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.
- Transaction A issues a SEND INVITE command; its conversation is now in pendreceive state.
- Transaction B issues a RECEIVE command; it is suspended until data is
received from transaction A.
- 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.
- Transaction B's RECEIVE command completes; EIBSYNC is set, and its conversation
is in syncsend state.
- Transaction B issues a SYNCPOINT command; the response is transmitted,
and its conversation is in send state.
- Transaction A's SYNCPOINT command completes, and its conversation is in receive state.
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.
- Transaction A issues a SEND LAST command; its conversation is now in pendfree state.
- Transaction B issues a RECEIVE command; it is suspended until data is
received from transaction A.
- 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.
- Transaction B's RECEIVE command completes; EIBSYNC and EIBFREE are set,
and its conversation is in syncfree state.
- Transaction B issues a SYNCPOINT command; the response is transmitted,
and its conversation is in free state.
- Transaction A's SYNCPOINT command completes, and its conversation is in free state.
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.
- 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
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- 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.
- Transaction A's ISSUE PREPARE command completes; its conversation is in syncsend state.
- Transaction A issues a SYNCPOINT command; the response is transmitted,
and its conversation is in send state.
- Transaction B's SYNCPOINT command completes, and its conversation is in receive state.

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.
- 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
- Transaction B issues a RECEIVE command which returns control immediately;
EIBERR and EIBSYNRB are set, and its conversation is in rollback state.
- 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.
- 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.
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.
- Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted,
and the transaction is suspended until a response is received from transaction
B.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- 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.
- 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.
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.
- 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.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- 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.
- 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.
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.
- Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted,
and the transaction is suspended until a response is received from transaction
B.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- Transaction B issues an ISSUE ERROR command; its conversation is in send state.
- 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.
- On behalf of transaction A, CICS sends a rollback request to transaction
B.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBERR and EIBSYNRB are set, and its conversation is in rollback state.
- 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.
- 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.

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.
- 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.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- Transaction B issues an ISSUE ERROR command; its conversation is in send state.
- Transaction B issues a WAIT command; the error indication is transmitted
to transaction A; transaction B's conversation is in send state.
- Transaction A's ISSUE PREPARE command completes; EIBERR is set; transaction
A's conversation is in receive state.
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.
- Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted,
and the transaction is suspended until a response is received from transaction
B.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- Transaction B issues an ISSUE ABEND command; theabend indication is transmitted;
transaction B's conversation is in free state.
- Transaction A abends with code ASP3.
- Transaction B issues a FREE command to free its conversation with transaction
A.
- Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources
remain consistent with transaction A's resources.
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.
- 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.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- Transaction B issues an ISSUE ABEND command; theabend indication is transmitted;
transaction B's conversation is in free state.
- 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.
- Transaction A issues a FREE command to free its conversation with transaction
A.
- Transaction A issues a SYNCPOINT ROLLBACK command in order that its resources
remain consistent with transaction A's resources.
- Transaction B issues a FREE command to free its conversation with transaction
A.
- Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources
remain consistent with transaction A's resources.

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.
- Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted,
and the transaction is suspended until a response is received from transaction
B.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- The session between transaction A and transaction B fails.
From this
point , the two transactions are independent of one another.
- 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.
- Transaction A abends with code ASP3.
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.
- Transaction A issues a SYNCPOINT command; the syncpoint request is transmitted,
and the transaction is suspended until a response is received from transaction
B.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- Transaction B issues a SYNCPOINT command; the response is transmitted,
and its conversation is in receive state.
- The session between transaction A and transaction B fails.
From this
point , the two transactions are independent of one another.
- Transaction A abends with code ASP3.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBERR and EIBFREE are set, and its conversation is in free state.
- Transaction B issues a FREE command to free its conversation with transaction
A.
- Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources
remain consistent with transaction A's resources.

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.
- 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.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBSYNC and EIBRECV are set, and its conversation is in syncreceive state.
- The session between transaction A and transaction B fails.
From this
point , the two transactions are independent of one another.
- Transaction A abends with code ASP1.
- Transaction B issues a SYNCPOINT command; its conversation is in receive state.
- Transaction B issues a RECEIVE command which returns control immediately;
EIBERR and EIBFREE are set, and its conversation is in free state.
- Transaction B issues a FREE command to free its conversation with transaction
A.
- Transaction B issues a SYNCPOINT ROLLBACK command in order that its resources
remain consistent with transaction A's resources.

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.
- 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
- Transaction B issues a RECEIVE command which returns control immediately;
EIBERR and EIBSYNRB are set, and its conversation is in rollback state.
- The session between transaction A and transaction B fails.
From this
point , the two transactions are independent of one another.
- Transaction B issues a SYNCPOINT ROLLBACK command; its conversation
is in free state.
- Transaction A's SYNCPOINT ROLLBACK command completes; its conversation
is in free state.
[[ Contents Previous Page | Next Page Index ]]