Safeguarding data integrity

If it is important to safeguard data integrity across connected transactions, then the CICS® synchronization commands shown in Table 27 are available.

Table 27. Synchronization commands for APPC basic applications
Conversation sync level Commands
0 None
1
GDS SEND CONFIRM
GDS ISSUE CONFIRMATION
2
GDS SEND CONFIRM
GDS ISSUE CONFIRMATION
SYNCPOINT
GDS ISSUE PREPARE
SYNCPOINT ROLLBACK
SRRCMIT30
SRRBACK30

These commands are defined in the following sections.

How to synchronize conversations using CONFIRM commands

A confirmation exchange affects a single, specified, conversation and involves only two commands:

  1. The transaction that is in send state (state 2) issues a GDS SEND CONFIRM command causing a request for confirmation to be sent to the partner transaction. The transaction is suspended awaiting a response.
  2. The partner transaction receives a request for confirmation. It can then respond positively by issuing a GDS ISSUE CONFIRMATION command. Alternatively, it can respond negatively by using the GDS ISSUE ERROR or GDS ISSUE ABEND commands.

The following sections describe these commands in more detail. The descriptions refer to the state tables for sync levels 1 and 2.

Requesting confirmation

The CONFIRM option on the GDS SEND command flushes the conversation send buffer; that is, it causes a real transmission to occur.

Data can be sent with the GDS SEND CONFIRM command. Either the INVITE or the LAST option can also be specified.

The send state (state 2) column of the state table for APPC basic conversations at sync level 1 in topic Table 37 shows what happens for the possible combinations of the CONFIRM, INVITE, and LAST options. After a GDS 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 GDS SEND LAST CONFIRM can by achieved by using the command sequence:

     GDS SEND LAST
     GDS SEND CONFIRM

Note from the state tables that the GDS SEND LAST puts the conversation into pendfree state (state 4), so data cannot be sent with a GDS 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. Whichever is used, the response from GDS SEND CONFIRM must always be checked. (See Checking the response to GDS SEND CONFIRM.)

Receiving and replying to a confirmation request

On receipt of a confirmation request, the CONVDATA and conversation state will be set depending on the request issued by the partner transaction. These together with the contents of the CDBCONF, CDBRECV, and CDBFREE fields are shown in Table 28.

Table 28. How confirmation requests affect the state and flags
Command issued by partner transaction Conversation state on receipt of request CDB- CONF on receipt of request CDB- RECV on receipt of request CDB- FREE on receipt of request
GDS SEND CONFIRM confreceive (state 6) X'FF' X'FF' X'00'
GDS SEND INVITE CONFIRM confsend (state 7) X'FF' X'00' X'00'
GDS SEND LAST CONFIRM conffree (state 8) X'FF' X'00' X'FF'

There are three ways of replying:

  1. Reply positively with a GDS ISSUE CONFIRMATION command.
  2. Reply negatively with a GDS ISSUE ERROR command. This reply puts the conversation into send state (state 2) regardless of the partner transaction request.
  3. Abnormally end the conversation with a GDS ISSUE ABEND command. This makes the conversation unusable and a GDS FREE command must be issued immediately.

Checking the response to GDS SEND CONFIRM

After issuing GDS SEND [INVITE|LAST] CONFIRM, it is important to test CDBERR to determine the partner transaction’s response. Table 29 shows the response received when the partner transaction issues different commands.

Table 29. Indicators of the partner transaction’s response
Command issued in reply by partner transaction Conversation state CDBERR CDBFREE
GDS ISSUE CONFIRMATION Dependent on original GDS SEND [INVITE|LAST] CONFIRM request X'00' X'00'
GDS ISSUE ERROR Receive (state 5) X'FF' X'00'
GDS ISSUE ABEND Free (state 12) X'FF' X'FF'

If CDBERR=X'00', the partner transaction has replied GDS ISSUE CONFIRMATION.

If the partner transaction replies GDS ISSUE ERROR, this is indicated by CDBERR (=X'FF') and the first two bytes of CDBERRCD=X'0889'. When the partner transaction replies GDS ISSUE ERROR in response to GDS SEND LAST CONFIRM, the LAST option is ignored and the conversation is not terminated. The conversation is switched to receive state (state 5).

If the partner transaction replies GDS ISSUE ABEND, both CDBERR and CDBFREE are both set (X'FF'), and the first two bytes of CDBERRCD contain X'0864'. The conversation is switched to free state (state 12).

How to synchronize conversations using SYNCPOINT commands

Data synchronization (SYNCPOINT and SYNCPOINT ROLLBACK) affects all connected conversations at sync level 2. The use of these commands in DTP is described in Syncpointing a distributed process.


30.
SAA verbs for SYNCPOINT and SYNCPOINT ROLLBACK respectively.

[[ Contents Previous Page | Next Page Index ]]