Unconditional deallocation request

If a deallocation is unconditional (specified with QUALIFY=FLUSH or QUALIFY=DATAFLU), the application program in RECEIVE state cannot stop the deallocation. The receiving application program cannot supply feedback information. If it does send error data, the data is lost. Error data unrelated to the deallocation request can also be lost. As an example, assume that an application program issues the following macroinstructions:

APPCCMD CONTROL=ALLOC, QUALIFY=IMMED
APPCCMD CONTROL=DEALLOC, QUALIFY=DATAFLU

For half-duplex sessions, VTAM® buffers the FMH-5 created as a result of the allocation, and nothing is sent to the partner LU until after the application program has ended the conversation. If the partner detects an error in the FMH-5, it has no way to report it to the application program that initiated the conversation, unless it starts another conversation. (The conversation is deallocated before the application program can determine whether the partner received data.) For half-duplex conversations on full-duplex-capable sessions, the FMH-5 is not buffered as a result of the allocation, but is sent immediately to the conversation partner.

If the potential loss of error information is unacceptable, the application must use a conditional deallocation request that includes a confirmation request.

When the application program requests conditional deallocation, it must wait for a confirmation response. The partner can reject the deallocation request.

The partner can respond negatively to the confirmation request, indicating an error, and also deallocate the conversation using one of the abnormal termination macroinstructions. This would be reported to the application program that is attempting to deallocate the conversation normally as one of the DEALLOCATE_ABEND return codes.

When the partner responds negatively to a confirmation request, it can send error data to the application program to be placed in the system log. The LOGRCV field in the RPL extension is set to YES to indicate this to the application program. When the LOGRCV field in the RPL extension is set to YES, the application program must issue APPCCMD CONTROL=RECEIVE, QUALIFY=SPEC|ISPEC to receive the error log data. If the data does not arrive, or has the wrong format, the application program must issue APPCCMD CONTROL=REJECT to both terminate the conversation and end the session. The application program includes a sense code on the macroinstruction to describe the exact nature of the error. Refer to the SNA Transaction Programmer's Reference Manual for LU Type 6.2 for a list of possible sense codes.

If the partner LU responds negatively to the confirmation request, VTAM puts the application program in RECEIVE state. The application program must wait for the partner LU to deallocate the conversation or attempt to enter SEND state before it can again try to deallocate the conversation.