If the CONFIRM bit is set in the What-Received field in an APPCCMD CONTROL=RECEIVE macroinstruction, the application program must respond to the confirmation request before it can issue any other APPCCMD macroinstructions. Application programs should check for the CONFIRM setting before attempting any action based on the setting of the SEND or DEALLOCATE bits.

The application program can use confirmation requests for a variety of reasons. It can issue the macroinstruction after an allocation request to determine whether the allocation was successful before sending data, or it can issue the confirmation request as an acknowledgment of data sent to a conversation partner. Confirmation requests also cause VTAM® to flush the SEND buffer.

The application program must ensure that a confirmation request is not issued on a conversation that was allocated with a synchronization level of "none." (The synchronization level is determined when the conversation is allocated by a field in the FMH-5.) If such a request is issued, a nonzero return code is received.

The application program does not have to supply any data to VTAM for a confirmation request. (On a QUALIFY=DATACON macroinstruction, however, the application program is sending data as well as a confirmation request, so data must be supplied.)

When the application program issues an APPCCMD macroinstruction that specifies a confirmation request, VTAM does not complete the macroinstruction until a response to the confirmation request is received from the partner application. The partner application can send a positive response to the confirmation request by issuing the APPCCMD CONTROL=SEND, QUALIFY=CONFRMD macroinstruction, which causes the application program's macroinstruction to complete with an RCPRI, RCSEC confirmation of OK. The partner application can send a negative response to the confirmation request by issuing APPCCMD CONTROL=SEND, QUALIFY=ERROR or one of the abnormal termination macroinstructions. VTAM interprets the FMH-7 received from the partner LU and completes the application program's macroinstruction with the appropriate RCPRI, RCSEC return codes.

If the application program receives a negative reply through a return code of USER_ERROR_CODE_RECEIVED__NEGATIVE_ RESPONSE (an RCPRI and RCSEC combination of X'005C' and X'0000', respectively), it is not immediately obvious whether the negative response was reported through the APPCCMD CONTROL=SEND, QUALIFY=ERROR macroinstruction or a DEALLOC macroinstruction. The application program must be able to determine this from the sense code returned in the SENSE field of the RPL. Alternatively, if the LOGRCV field indicates that error log data is being sent to the application program, the application program can receive the data. The APPCCMD CONTROL=RECEIVE macroinstruction that receives the error log data completes with a return code indicating the conversation has been deallocated, if the negative confirmation request was generated as part of a deallocation request.

The APPCCMD CONTROL=PREPRCV macroinstructions are somewhat different than the other macroinstructions. The application program can specify that the macroinstruction cannot complete execution until it has received data from the partner LU, instead of a positive response to the confirmation request. This is done by specifying LOCKS=LONG in the RPL.

The application program can be assured that data or control information is available to complete an APPCCMD CONTROL=RECEIVE, QUALIFY=SPEC|ISPEC macroinstruction when a LOCKS=LONG PREPRCV request completes. This allows the application program to avoid tying up buffer space waiting for an APPCCMD CONTROL=RECEIVE, QUALIFY=SPEC to complete, because this request cannot complete until something is available to receive on the conversation.