Half-duplex conversations are normally deallocated by the transaction program in SEND or PENDING_SEND state. The deallocation can be unconditional or conditional. It can also include a request to send data or transmit buffered data to the partner LU.
Normal conversation deallocation occurs when the side of the conversation in a sending state issues an APPCCMD CONTROL=DEALLOC macroinstruction. The partner application program is informed of the deallocation request through feedback on an APPCCMD macroinstruction (probably an APPCCMD CONTROL=RECEIVE macroinstruction).
The application program in a receiving state can be informed of the deallocation by way of a bit (DEALLOCATE) in the What-Received field of the RPL extension on an APPCCMD CONTROL=RECEIVE macroinstruction. It also can be informed of the deallocation if it attempts to issue an APPCCMD CONTROL=SEND, QUALIFY=ERROR macroinstruction. If it attempts to issue an APPCCMD CONTROL=SEND, QUALIFY=ERROR macroinstruction, it receives an error return code indicating the partner has deallocated the conversation.
If the application program will do neither, it should use the QUALIFY=FLUSH form of the macroinstruction. The QUALIFY=DATAFLU form sends additional data and deallocates the conversation. The QUALIFY=CONFIRM form sends a confirmation request and deallocates the conversation. The QUALIFY=DATACON form sends both data and a confirmation request in addition to deallocating the conversation. These choices are shown in Table 1.
Sends Data | Confirm | Macroinstruction |
---|---|---|
Yes | Yes | DEALLOC/DATACON |
No | Yes | DEALLOC/CONFIRM |
Yes | No | DEALLOC/DATAFLU |
No | No | DEALLOC/FLUSH |