Consider the following situation. The application program (which is the bidder) and the LU (the first speaker) are in a session involving half-duplex contention and the use of brackets. At this point, assume that they are within a bracket. They have agreed in the session parameters to conditional bracket termination; that is, a bracket is not terminated until the sender of EB gets a response to the chain containing EB.

The application program then sends a chain containing EB. Simultaneously, the LU sends a data request that was meant to be within the current bracket. If RESPOND=NQRESP is used for the EB chain in VTAM®, it is possible for the application program to get the response to the EB chain before it gets the data request. If that happens, the application program fails to know that the LU meant for the data request to be within the bracket.

To avoid this problem, the application program should specify NIB PROC=ORDRESP and send the EB chain with SEND RESPOND=QRESP. That parameter causes VTAM to treat the response as if it were a normal-flow request. Because the LU must send the response to the request specifying EB after it sends the in-bracket request, and because the response is treated as a normal-flow request, the application program gets the in-bracket request and the response in that order, which is the correct order.

Because the response to the EB request is treated as a normal-flow request, it does not cause scheduling of an RESP exit routine, nor can it cause completion of RECEIVE RTYPE=RESP. The SEND macroinstructions used to send the chain containing EB and RESPOND=QRESP must specify POST=SCHED. The response itself (because it is treated as a normal-flow request) must be obtained with RECEIVE RTYPE=DFSYN (not RTYPE=RESP).

For more information on the QRESP and NQRESP parameters in the RESPOND operand, see Controlling the handling of normal-flow responses.