In cases where the conversation is unconditionally deallocated, the receiving application program can do little more than recognize that its partner has deallocated the conversation. Receiving application programs are informed by the deallocate indicator (RPL6WDAL) in the What-Received field in the RPL extension. In such cases, the deallocate bit is set on, and the confirm bit is set off. The application program does not have to report errors to the partner because the conversation is gone. The application program can attempt to initiate a new conversation with the former partner and attempt to communicate the unreported error.
If a confirmation request is included with the deallocation request (RPL6WCFM is set on), the receiving application program has much more flexibility. The conversation is not deallocated unless the application program responds to the confirmation request positively. An application program uses the APPCCMD CONTROL=SEND, QUALIFY=CONFRMD macroinstruction to respond positively. It can issue the APPCCMD CONTROL=SEND, QUALIFY=ERROR macroinstruction or one of the abnormal termination macroinstructions to respond negatively. If it uses APPCCMD CONTROL=SEND, QUALIFY=ERROR, it is placed in SEND state. An abnormal termination macroinstruction ends the conversation.
On both the APPCCMD CONTROL=SEND, QUALIFY=ERROR macroinstruction and the various forms of APPCCMD CONTROL=DEALLOC|DEALLOCQ that abnormally terminate the conversation, the application program can specify error log data on the macroinstruction. The error data is pointed to by the AREA field of the RPL. The length of the error data is indicated by the RECLEN field. If RECLEN has a value of 0, the application program has not provided any error data. Error data is in the form of a GDS error log variable. For information on the layout of the error log variables, see Error log variables.