For every SNA chain of data sent or received for which responses are outstanding (RQE or RQD), the local node maintains a correlation table entry (CT). If the CTs become depleted, then the local node will terminate the session using the most CTs. A Status-Error message (code 0x46) and a Close(PLU) Request are sent to the application, and a TERM-SELF message is sent to the host. CT shortages (inbound) can be avoided by sending CD (for half-duplex) data, or data ACKRQD, or any Status-Control(CHASE), or Status-Control(LUSTAT) with ACKRQD. Outbound shortages can be avoided by sending courtesy acknowledge messages as described in Opening the PLU Connection.
The local node sends chains of data to the host with their chain response mode specified as follows:
If the application sends a Data message to the local node with the ACKRQD field set, and the BIND parameters specified that the secondary uses definite or definite/exception response mode.
If the application sends a Data message to the local node without the ACKRQD field set, and the BIND parameters specified that the secondary uses exception or definite/exception response mode.
If the application sends a Data message to the local node without the ACKRQD field set, and the BIND parameters specified that the secondary uses no-response mode.
If the setting of ACKRQD on a Data message from the application does not reflect the chain response mode specified in the BIND parameters, the local node returns a Status-Acknowledge(Nack-2) indicating a noncritical error code; for example, if the application specifies ACKRQD but the BIND parameters do not permit the local node to send definite response chains.
In case 1, the application receives an acknowledgment to all FMD chains it sends to the local node:
In case 2, the application only receives an acknowledgment of an FMD chain it sends to the local node for:
In case 3, the application only receives an acknowledgment of an FMD chain it sends to the local node when the node detects an error in the message and sends the application a Status-Acknowledge(Nack-2). The only dissent that the host can make is to send a subsequent LUSTAT 0x400A (no response not supported) with the sequence number of the request in the sense qualifier field; this is presented to the application as a Status-Control(LUSTAT) as usual.
Whenever an application receives a Status-Acknowledge(Ack) or Status-Acknowledge(Nack-1), it implicitly confirms receipt by the partner half-session in the host of all previously sent chains.
In case 2, the application does not usually receive such responses from the host to chains it has sent, and in case 3, the application never receives such responses. Therefore, to get the host to confirm receipt of all previously sent chains, the application should issue a Status-Control(CHASE) Request with ACKRQD set. This causes the local node to generate an SNA CHASE request to the host. The receipt of the response to this CHASE confirms that the host has received this CHASE request and all previous chains sent by the application. The local node issues a Status-Control(CHASE) Acknowledge to notify the application that this is so.
The following three figures illustrate the inbound 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, an application sets the ACKRQD field in an inbound data chain to get the host to confirm receipt of the chain and all previously sent chains.
In the following illustration, the Status-Acknowledge(Nack-1) rejects the last chain, but confirms receipt by the host of all previously sent data chains.
In the following illustration, the application uses a Status-Control(CHASE) to get the host to confirm receipt of the corresponding CHASE request and all previously sent chains.
