|
|
|
|
APPC operates as a half-duplex process, which means that, at any time, only one of the two TPs is permitted to send data. In general, one TP will send a certain amount of data, and then do one of the following:
Ask the other TP to confirm receipt of the data
Allow the other TP to send
At any one time, the TP regards the conversation as being in a particular conversation state; the conversation state governs which APPC verbs can be issued by a TP at a particular time. For example, a TP cannot issue the MC_SEND_DATA verb if the conversation is not in Send or Send-Pending state. For more information about the APPC verbs that can be issued in each state, see APPC State Changes.
Following is a list of possible conversation states:
The TP has received a request for confirmation of receipt of data; it must respond positively or send error information to the partner TP.
The TP has received a request for confirmation and must respond positively or send error information. If the TP responds positively, the partner TP deallocates the conversation.
The TP has received a request for confirmation; it must respond positively or send error information. After responding, the TP can begin to send data.
The TP is receiving data asynchronously. The TP can perform other processing not related to this conversation. When the TP finishes receiving data, the state is usually Receive.
The TP can receive application data and status information from the partner TP. When the conversation is in Receive state, the TP can also send error information and request permission to send data.
The TP can send data to the partner TP and request confirmation. When the conversation is in Send state, the TP can also begin to receive data, which causes the state to change to Receive.
The TP has received data together with a SEND indication from the partner TP. This state is similar to Send state, except that the TP can use an extra parameter on the [MC_]SEND_ERROR verb to indicate the source of a detected error.
It is the conversation rather than the TP that is in a particular state. A TP may be conducting several conversations, each of which is in a different state. If a conversation is said to be in Send state, this always means that from the viewpoint of the local TP, the conversation is in Send state. To the partner TP, the conversation is in another state (such as Receive).
A change in the conversation state occurs on the completion of an APPC verb. The state change can result from any of the following:
A verb issued by the local TP (for example, issuing RECEIVE_AND_WAIT in Send state changes the conversation state to Receive)
A verb issued by the partner TP (for example, if the partner TP issues the CONFIRM verb, the local TP receives indication of this on one of the RECEIVE verbs; at this point the conversation changes from Receive to Confirm state)
An error condition
The new state of the conversation generally depends on the primary return code of the completed APPC verb. For more information, see the individual verb descriptions in APPC Control Verbs and APPC Conversation Verbs, or see APPC State Changes.
A state check (state error) occurs when a TP issues an APPC verb, and the conversation is not in the appropriate state. For instance, a state check would occur if a TP issued the MC_SEND_DATA verb while the conversation was in Receive state. When a state check occurs, APPC does not execute the verb; it returns state-check information through primary and secondary return codes. For more information about the state check error codes that can be returned for each verb, see the individual verb descriptions in APPC Control Verbs and APPC Conversation Verbs.
|
|
|
 |
|