Obtaining Information about the Conversation

After accepting the conversation, the partner TP can then use the conversation ID as input to these services to obtain more information about the conversation:

Get_Type

Tells the caller what type of conversation is in effect (basic or mapped). This service allows a TP to handle requests from callers who might specify either type of conversation. The TP can use conditional logic to send and receive basic or mapped data depending on the type in use.

Get_Attributes

Tells the caller the LU, mode name, sync_level, the conversation correlator, and other information that applies to the caller in the current conversation. This allows the TP to run under different combinations of the above, using conditional logic to function appropriately. For example, a partner TP can use the conversation correlator, which uniquely identifies a conversation, to correlate requests with responses from an alternate transaction scheduler.

When a partner TP allocates a conversation with a TP running on MVS, the system on which the partner TP is running generates the conversation correlator, and sends the correlator to APPC/MVS in the FMH-5 for the Allocate request. After the scheduler processes the request, the scheduler sends the correlator back to the partner TP as data over the conversation. The partner TP can then correlate the original request with the response from the scheduler.

Note: When MVS is the partner system, it only generates unique conversation correlators for syncpoint conversations. For all others, MVS always provides a conversation correlator that has the value zero.

Figure 1 shows an example of how a scheduler can process a conversation correlator. The figure illustrates the following scenario:

The partner TP allocates a conversation with a local TP on MVS. The partner system sends the conversation correlator to APPC/MVS in the FMH-5 that contains the request.
The partner TP calls the Send_Data service to put a block of data in a buffer for sending.
The partner TP calls the Get_Attributes service to receive the conversation correlator assigned to the conversation.
The partner TP calls the Deallocate service to end the conversation and force the LU to send the buffered data.
The transaction scheduler receives the request and schedules the transaction. The scheduler receives the correlator from the IXCMSGI message buffer.
The scheduler allocates a conversation back to the partner TP.
The scheduler sends the conversation correlator to the partner TP as data over the conversation. The scheduler also sends the message that results from the execution of the TP.
The scheduler calls the Deallocate service, with a Deallocate_type of Confirm, to end the conversation and force the LU to send the buffered data.
The partner TP receives the conversation correlator.
The partner TP validates that the conversation correlator that it is the same as the correlator returned on the call to Get_Attributes in step 3 above.
The partner TP calls the Confirmed service to send a confirmation reply to the transaction scheduler.

In Figure 1, "CC" indicates the conversation correlator.

Figure 1. Example Use of the Conversation Correlator