Confirmation Processing

The sequence of events for confirmation processing is as follows:

1. Establish the synchronization level.
2. Send a confirmation request.
3. Receive data and confirmation request.
4. Respond to the confirmation request.
5. Deallocate the conversation.

Using confirmation processing, a TP sends a confirmation request with the data; the partner TP confirms receipt of the data or indicates that an error occurred. Each time the two TPs exchange a confirmation request and response, they are synchronized.

Note  Although the example in this section does not show this, any TP can send or receive data, regardless of whether the TP is the invoking TP or the invokable TP.

The following example illustrates confirmation processing.

Initialize_Conversation

Set_Sync_Level
  (sync_level=CM_CONFIRM)

Allocate

Send_Data

Confirm

Accept_Conversation

Receive
    (data_received=
      CM_COMPLETE_DATA_RECEIVED)
    (status_received=
      CM_CONFIRM_RECEIVED)

Confirmed

(return_code=CM_OK)

Send_Data

Deallocate

Receive

(status_received=
      CM_CONFIRM_DEALLOC_RECEIVED)

Confirmed

(return_code=CM_OK)

Establishing the Synchronization Level

The Set_Sync_Level call lets you override the default synchronization level of the conversation. The synchronization level is one of the conversation's characteristics. There are two possible synchronization levels:

• CM_CONFIRM, under which the TPs can request confirmation of receipt of data and respond to such requests.
• CM_NONE, the default, under which confirmation processing does not occur.

The Initialize_Conversation call sets the default characteristics of a conversation. There are several calls that begin with Set_. These calls let you override the default conversation characteristics.

Sending a Confirmation Request

Issuing the Confirm call has two effects:

• It flushes the local LU's send buffer and sends any data contained in the buffer to the partner TP.
• It sends a confirmation request that the partner TP receives through the status_received parameter of a Receive call.

After issuing Confirm, the local TP waits for confirmation from the partner TP.

Receiving a Confirmation Request

The status_received parameter of the Receive call indicates any future action required by the local TP.

In the example, the first Receive has a status_received of CM_CONFIRM_RECEIVED, indicating that a confirmation is required before the partner TP can continue.

Responding to a Confirmation Request

The partner TP issues the Confirmed call to confirm receipt of data. This frees the local TP to resume processing.

Deallocating the Conversation

Because the synchronization level of the conversation is set to CM_CONFIRM, Deallocate sends a confirmation request with the data flushed from the buffer.

For the second Receive call, status_received is CM_CONFIRM_DEALLOC_RECEIVED, indicating that the partner TP requires a confirmation, generated by the Confirmed call, before the conversation can be deallocated.