If it is important to safeguard data integrity across connected transactions, then the CICS® synchronization commands shown in Table 5 are available.
Conversation sync level | Commands |
---|---|
0 | None |
1 |
SEND CONFIRM ISSUE CONFIRMATION |
2 |
The above commands are defined in the sections that follow.
A confirmation exchange affects a single specified conversation and involves only two commands:
The following sections describe these commands in more detail. The descriptions refer to the state tables for sync levels 1 and 2.
The CONFIRM option of the SEND command flushes the conversation send buffer; that is, it causes a transmission to occur. When the conversation is in send state (state 2), you can send data with the SEND CONFIRM command. You can also specify either the INVITE or the LAST option.
The send state (state 2) column of the state table for APPC mapped conversations at sync level 1 on topic Table 14 shows what happens for the possible combinations of the CONFIRM, INVITE, and LAST options. After a SEND CONFIRM command, without the INVITE or LAST options, the conversation remains in send state (state 2). If the INVITE option is used, the conversation switches to receive state (state 5). If the LAST option is used, the conversation switches to free state (state 12).
A similar effect to SEND LAST CONFIRM can by achieved by using the command sequence:
SEND LAST
SEND CONFIRM
Note from the state tables that the SEND LAST puts the conversation into pendfree state (state 4), so data cannot be sent with a SEND CONFIRM command used in this way.
The form of command used depends on how the conversation is to continue if the required confirmation is received. However, the response from SEND CONFIRM must always be checked. See Checking the response to SEND CONFIRM.
On receipt of a confirmation request, the EIB and conversation state will be set depending on the request issued by the partner transaction. These together with the contents of the EIBCONF, EIBRECV, and EIBFREE fields are shown in Table 6.
Command issued by partner transaction | Conversation state on receipt of request | EIBCONF on receipt of request | EIBRECV on receipt of request | EIBFREE on receipt of request |
---|---|---|---|---|
SEND CONFIRM | confreceive (state 6) | X'FF' | X'FF' | X'00' |
SEND INVITE CONFIRM | confsend (state 7) | X'FF' | X'00' | X'00' |
SEND LAST CONFIRM | conffree (state 8) | X'FF' | X'00' | X'FF' |
There are three ways of replying:
After issuing SEND [INVITE|LAST] CONFIRM, it is important to test EIBERR to determine the partner’s response. Table 7 shows how the partner’s response is indicated by EIB flags and the conversation states.
Command issued in reply by partner transaction | Conversation state on receipt of response | EIBERR on receipt of response | EIBFREE on receipt of response |
---|---|---|---|
ISSUE CONFIRMATION | dependent on original SEND [INVITE|LAST] CONFIRM request | X'00' | X'00' |
ISSUE ERROR | receive (state 5) | X'FF' | X'00' |
ISSUE ABEND | free (state 12) | X'FF' | X'FF' |
If EIBERR=X'00', the partner has replied ISSUE CONFIRMATION.
If the partner replies ISSUE ERROR, this is indicated by EIBERR=X'FF' and the first two bytes of EIBERRCD = X'0889'. When the partner replies ISSUE ERROR in response to SEND LAST CONFIRM, the LAST option is ignored and the conversation is not terminated. The conversation state is switched to receive state (state 5).
If the partner replies ISSUE ABEND, your transaction will be abended AZCH. In addition, EIBERR and EIBFREE are set, and the first two bytes of EIBERRCD=X'0864'. The conversation is switched to free state.
Data synchronization (the SYNCPOINT and SYNCPOINT ROLLBACK commands) affects all connected conversations at sync level 2. The use of these commands in DTP is described in Syncpointing a distributed process.