Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The sequence of events for confirmation processing is as follows:
Establish the synchronization level.
Send a confirmation request.
Receive data and confirmation request.
Respond to the confirmation request.
Deallocate the conversation.
Using confirmation processing, a transaction program (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 table illustrates the steps involved in confirmation processing.
| Step | Issued by the invoking TP | Issued by the invokable TP |
|---|---|---|
| 1 | Initialize_Conversation | |
| 2 | Set_Sync_Level (sync_level=CM_CONFIRM) | |
| 3 | Allocate | |
| 4 | Send_Data | |
| 5 | Confirm | |
| 6 | Accept_Conversation | |
| 7 | Receive (data_received= CM_COMPLETE_DATA_RECEIVED) (status_received= CM_CONFIRM_RECEIVED) | |
| 8 | Confirmed | |
| 9 | (return_code=CM_OK) | |
| 10 | Send_Data | |
| 11 | Deallocate | |
| 12 | Receive | |
| 13 | (status_received= CM_CONFIRM_DEALLOC_RECEIVED) | |
| 14 | Confirmed | |
| 15 | (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.