This section describes the outbound data flows from the local node to the application. The overall structure of the protocols described applies to the SSCP and PLU connections, but certain features (such as the use of delayed request mode) are only applicable to the PLU connection.
The local node presents data originating at the host to the application on different connections, depending on the SNA session on which the data flows, as follows:
For all connections, only FMD requests are presented to the application as Data messages (that is, with message-type = DATAFMI). DFC and session control requests are used to generate Status-Control messages (see Status-Control Message).
The local node performs the data flow control state changes required by the RH indicators in the request, before sending a Data message to the application.
The SNA request TH (transmission header) and RH indicators are not available to the application on outbound Data messages. Instead, the local node provides application flags in the Data message header that reflect the settings of a subset of the RH indicators, but are interpreted by the local node to shield the application from the more obscure aspects of chaining and bracket usage. See Application Flags for a description of the available flags and the way in which the local node uses them on outbound data.
For outbound data, the first byte is RU[0] for standard FMI, and TH[0] for the LUA variant of FMI.
All Data messages from the local node to an application contain a message key. The local node maintains a unique message key sequence for each outbound data flow to an application. When the local node sends a Data message to an application on a particular connection, it places the next message key in the outbound sequence into the message header, sets the application flags, and sends the message to the application. This means that the message key uniquely identifies a Data message on a particular connection between the local node and the application. Note that the local node also places message keys on outbound Status-Control Request messages.
The acknowledgment protocol enforced by SNA Server reflects the chain response protocol and request mode in use on the SNA session, as follows:
Note that SNA Server enforces the equivalent of immediate response mode for the outbound data acknowledgment protocol for all connections. That is, the application must send acknowledgments in order.
If the local node sets the ACKRQD field in the message header of a Data message to the application, it indicates that an acknowledgment to this Data message is required. The application acknowledges an outbound Data message by sending a Status-Acknowledge message to the local node on the same connection, which contains the same message key and sequence number fields as the Data message.
On receipt of a Status-Acknowledge(Ack), the local node correlates the message key with outstanding outbound messages and generates an SNA positive response to the appropriate SNA request.
The application should use the Status-Acknowledge(Nack-1) message as a negative acknowledgment. On receipt of a Status-Acknowledge(Nack-1), the local node correlates the message with outstanding outbound messages and generates an SNA negative response plus sense data to the appropriate SNA request. The application supplies the sense data that should accompany the negative response as part of the Status-Acknowledge(Nack-1) message and must include the same message key, application flags, and sequence number fields as the Data message to which this is a negative acknowledgment.
Status-Control messages caused by expedited-flow requests can be sent at any time and do not affect the sending of positive or negative acknowledgment to normal flow outbound Data messages. The fact that they can occur between an outbound Data message and the matching Status-Acknowledge message is purely coincidental. See Status-Control Message for details of which Status-Control messages correspond to SNA requests.
If errors are detected in the format of a normal flow request from the host or the request is inappropriate for the state of the session, the local node generates an error Data message for the application with the following characteristics:
The application should return a Status-Acknowledge(Ack), and the local node generates a negative response carrying the sense code appropriate to the detected error. This mechanism:
On sessions where the application is receiving a series of RQE chains, the local node will be retaining correlation information for each chain (in case the application wishes to send negative responses to any of the chains). If the local node runs out of correlation table entries, it will attempt to allocate more entries and (if this fails) will be forced to terminate sessions. To prevent this, the application should provide Status-Acknowledge(Ack) messages for RQE data that it does not wish to reject in this case; a response after five consecutive RQE chains should be sufficient. Such messages are referred to as courtesy acknowledgements and do not give rise to a response to the host, but merely free internal correlation data.
The following six figures illustrate the data acknowledgment protocol enforced between the local node and the application, and show the effects of the application generating positive and negative Status-Acknowledge messages.
The figures show:
For simplicity, all messages are assumed to be FM data flowing on the same PLU session.
In the following illustration, the application accepts a Data message corresponding to a definite-response RU.
In the following illustration, the application accepts a Data message corresponding to a multi-RU definite-response chain.
In the following illustration, the application rejects a Data message corresponding to a definite-response chain.
In the following illustration, the application rejects a Data message corresponding to a multi-RU definite-response chain.
In the following illustration, the local node enforces immediate response mode; that is, responses must be sent in sequence. The application rejects the second exception-response chain and accepts the definite-response chain, which implies acceptance of the third exception-response chain.
In the following illustration, the local node detects a chaining error (RQD but not EC) in data destined for the application (this example requires the receive check 0x4007 to be in force — see Opening the SSCP Connection).
