Confirmation and Rejection of Outbound Data

The local node sends chains of data from the host to the application with their ACKRQD field set as follows:

1. ACKRQD set

   If the corresponding SNA request was received specifying definite response, and the BIND parameters specify that the primary uses definite or definite/exception chain response mode.

2. ACKRQD not set, response mode

   If the corresponding SNA request was received specifying exception response, and the BIND parameters specify that the primary uses exception or definite/exception chain response mode.

3. ACKRQD not set, no-response mode

   If the corresponding SNA request was received specifying no response, and the BIND parameters specify that the primary uses no-response chain response mode.

In case 1, the application should always send an acknowledgment as follows:

• If the application accepts the data, it should return a Status-Acknowledge(Ack) message.
• If the application wishes to reject the data, it should return a Status-Acknowledge(Nack-1) message carrying the appropriate SNA sense codes.

In case 2, the application should only send an acknowledgment in the following cases:

• If the application wishes to reject the data, it should return a Status-Acknowledge(Nack-1) message carrying the appropriate SNA sense codes.
• The application can send a courtesy acknowledgement (see Outbound Data) to an RQE message to clear up correlation data within the local node.

In case 3, the application should not send acknowledgments; however, the sending of a Status-Acknowledge(Ack) or Status-Acknowledge(Nack-1) by the application has no effect—it is discarded.

Whenever an application sends a Status-Acknowledge(Ack) or Status-Acknowledge(Nack-1) to a received Data message, it implicitly confirms receipt of this and all previously-received Data messages.

In case 2, the host can issue a CHASE request; the local node sends a Status-Control(CHASE) Request with ACKRQD set to the application. When the application is in a position to confirm receipt of all outstanding data, it should issue a Status-Control(CHASE) Acknowledge message, which the local node converts into a positive response to CHASE for the host.

In cases 1 and 2, if the local node detects an error in a received request, it converts the request into a special Data message, which it passes to the application. Regardless of the chain response mode specified for the secondary in the BIND parameters, this Data message has the following characteristics:

• ACKRQD is set; that is, the application must confirm receipt using a Status-Acknowledge(Ack) message.
• The SDI application flag is set to indicate that this is a special Data message used to inform the application of an error detected by the local node.
• The ECI application flag is set to indicate that the received chain has now terminated.
• The first four bytes of the buffer element hold the SNA sense codes detected by the local node that caused the termination.

This mechanism allows:

• The application to reject any previously-received Data messages.
• The local node to inform the application of any errors it detects in received requests.
• The local node to send negative responses in the correct order.

The following three figures illustrate the outbound data confirmation and rejection protocols between the local node and the application and how those protocols relate to the underlying SNA protocols.

In the first illustration, the host sends a definite response chain to get the application to confirm receipt of the RQD request and all previously sent RQE chains.

In the following illustration, a Status-Acknowledge(Nack-1) from the application rejects the last chain and confirms receipt of all previously sent data chains.

In the following illustration, the host sends a CHASE request to get the application to confirm receipt of the CHASE and all previously sent chains.