Controlling the handling of normal-flow responses

The macroinstruction that sends a normal-flow request can be used to control how VTAM® handles the response to that request. The ability to exercise that control depends on whether PROC=NORDRESP or PROC=ORDRESP was specified in the NIB when the session was established.

If PROC=ORDRESP was in effect in the NIB when the session was established, the programmer establishes, at the time the normal-flow request is sent, the way in which VTAM handles the response, as follows:

When the request is sent with RESPOND=NQRESP in the RPL, the response is handled as an ordinary normal-flow response—meaning that it can cause completion of a POST=RESP operation, scheduling of a RESP exit routine, and completion of RECEIVE RTYPE=RESP.
When the request is sent with RESPOND=QRESP, the response is not handled as a response, but instead is handled almost as if it is an incoming normal-flow request from the LU. Such a response is called a DFSYN response. A DFSYN response does not cause scheduling of a RESP exit routine and does not cause completion of a RECEIVE RTYPE=RESP. It does, however, cause completion of the original SEND operation if the operation specified POST=RESP. If POST=RESP was not specified in the original operation, the application program can get the response by using a RECEIVE RTYPE=DFSYN and testing the RTYPE field of the RPL upon completion. If RTYPE=(DFSYN,RESP) after completion, the program knows it has received a normal-flow response instead of a normal-flow request.

If PROC=NORDRESP was in effect when the session was established, the programmer has no control over how VTAM handles the responses. In this case, all normal-flow responses (regardless of the QRESP setting) are handled as if NQRESP had been specified in the original SEND. Thus, PROC=NORDRESP is specified in the NIB when a user wants the application program to be executed in VTAM.

Additionally, the PROC=NORDRESP or PROC=ORDRESP setting controls how VTAM interprets the RPL POST and RESPOND operands for normal-flow requests.

The NQRESP response and QRESP response differ in that the NQRESP response is handled as a regular normal-flow response and is presented to the application program in sequence with other normal-flow responses; the QRESP response is treated as an incoming normal-flow request and is presented to the application program in sequence with those requests. A response that satisfies a SEND macroinstruction that specifies POST=RESP and either QRESP or NQRESP is always delivered immediately by VTAM. This response could, therefore, get ahead of other normal-flow responses.

An application program sends most of its normal-flow requests with RESPOND=NQRESP. However, you might want to use QRESP with bracket protocol. See The Chase request for a description of QRESP in relation to the Chase request. See Special use of RESPOND=QRESP with bracket protocol for a description of the bracket protocols and how they are used with QRESP. All requests of a chain should have the same QRESP or NQRESP setting.

When an application program receives a series of requests and responses on a session and either the NIB specifies PROC=NORDRESP or the requests from the application program specify RESPOND=NQRESP, all of the requests arrive in the same order that they are sent, and all of the responses arrive in the same order that they are sent, but the order of the combination of requests and responses can be changed. For example, request 1 always arrives before request 2, and response 2 always arrives before response 3; however, a response sent after a particular request can arrive before it. As an example, the LU sends the following on a session:

Response 1, Request 1, Request 2, Request 3,
Response 2, Response 3, Request 4

They could arrive at the application program as follows:

Response 1, Response 2, Request 1, Response 3,
Request 2, Request 3, Request 4

If the NIB specifies PROC=ORDRESP and the requests from the application program specify RESPOND=QRESP, all the responses (which are now DFSYN responses) and normal-flow requests arrive in the same order in which they are sent. (In effect, VTAM handles a DFSYN response as it does a normal-flow request.) For example, if the LU sends the following:

Response 1, Request 1, Request 2, Request 3,
Response 2, Response 3, Request 4

They arrive in the same order at the application program as follows:

Response 1, Request 1, Request 2, Request 3,
Response 2, Response 3, Request 4

When a program sends a normal-flow request on a session established with the NIB PROC=ORDRESP, the POST operand in the macroinstruction can be set to SCHED or RESP, and the completion of the macroinstruction is based on that setting. If NORDRESP is specified in the NIB, when a normal-flow data-flow-control request (as opposed to a data request) is sent, VTAM ignores the POST operand and automatically establishes POST=RESP (meaning that the operation is not completed until the response has been received). Similarly, if ORDRESP is specified, the application program must specify the correct RESPOND setting for normal-flow data-flow-control requests (ordinarily (NEX,FME)). For NORDRESP (unless OPTCD=USERRH), the (NEX,FME) value of RESPOND is assumed automatically by VTAM. For USERRH considerations, see Relationship to NIB PROC=ORDRESP or NORDRESP operand.