This section describes inbound data flows from the application to the local node. The overall structure of the protocols described applies to the SSCP and PLU connections, but more complex aspects (such as the use of delayed request mode) are only applicable to the PLU connection.
The application can send inbound data on any of the three connections, as follows:
The application cannot use Data messages to send DFC or session control request messages to the host. Instead it must use Status-Control messages (see Status-Control Message for further details).
For all three connections, the application must fill in certain key fields in the Data message's header. In particular it must:
The nxtqptr, hdreptr and numelts fields in the message header, and the elteptr and startd fields in the message elements are set up by SNA Server's buffer management routines (see The DL-BASE/DMOD Interface). The application is responsible for setting the endd field.
Where the application does not have access to these routines (for example, where the operating environment does not support intertask procedure calls and shared memory), all the fields in the header must be set by the application.
The TH and RH indicators are not available to the application on inbound Data messages. The application should set the appropriate application flags in the message header to control chaining, direction, and so on—see Application Flags for a description of the available application flags for inbound data and later topics in this section for a description of how the flags are used to control inbound data flows.
For inbound data, the first byte is RU[0] for standard FMI.
The message key supplied by the application in the inbound Data message header is used by the local node to indicate which Data message on this connection an outbound Status-Acknowledge refers to. The application should maintain a unique message key sequence for the inbound data flow on each connection it has with the local node, so that the application can use the message key to correlate inbound Data messages and outbound Status-Acknowledge messages on the connection. Note that the application must also provide a message key on Status-Control Request messages to differentiate between multiple RQE LUSTAT messages.
The inbound data acknowledgment protocol reflects the secondary chain response protocol and request mode in use on the session, as follows:
If the application sets the ACKRQD field in the message header of a Data message, it indicates that it requires an acknowledgment to this Data message. The local node acknowledges an inbound Data message by sending a Status-Acknowledge message to the application on the same connection and using the same message key as the Data message (see the first figure at the end of this topic).
The local node processes inbound Data messages from the application through its internal state machines, assigns the correct SNA sequence number or an identifier for this flow, and sends the data in a request to the host. The chain-response type of the request depends on whether ACKRQD was set in the Data message and the session parameters.
The local node maps a positive response from the host to a Status-Acknowledge(Ack) to the application. The application can use the message key in the Status-Acknowledge to correlate the acknowledgment with the original Data message. Therefore, receipt of a Status-Acknowledge(Ack) for a particular Data message implies that the local node has received a positive SNA response from the host to the inbound SNA request (see the second figure at the end of this topic).
Note that responses are absorbed on the SSCP-PU session.
Note that outbound Status-Acknowledge(Ack) messages contain application flags and a sequence number. The application flags reflect the RH indicators in the response. The sequence number is the SNA sequence number from the response, and provides a mechanism for applications using TS profile 4 to track the SNA secondary sequence number corresponding to a unit of work.
The local node maps a negative response from the host to a Status-Acknowledge(Nack-1) message to the application. The application can use the message key in the Status-Acknowledge to correlate the negative acknowledgment with the original Data message. The outbound Status-Acknowledge(Nack-1) message contains the SNA sense codes and sequence number from the negative response (see the third and fourth figures at the end of this topic).
If the local node detects an error in the format of an inbound Data message, or the Data message is not appropriate to the current state of the session, it sends a Status-Acknowledge(Nack-2) to the application containing an error code (see Error and Sense Codes for a list of error codes). The local node does not send a request to the host corresponding to the Data message in error and does not advance the SNA sequence number for the session. The application can use any message key in its next inbound Data message (assuming the error does not cause a critical failure).
An example of a serious chaining error, where the application sends a Data message with ACKRQD but without ECI in the application flags, is shown in the last figure at the end of this topic. Note that after detecting this particular error, the local node marks the application's connection as critically failed, closes the connection, and sends a TERM-SELF request to the SSCP to elicit an UNBIND (see Recovery).
Inbound Status-Control messages, which cause the generation of expedited-flow requests, can be sent at any time and do not affect the sending of a positive or negative acknowledgment to inbound Data messages. See Status-Control Message for details of which Status-Control messages correspond to SNA expedited-flow requests.
The following five figures illustrate examples of the inbound data acknowledgment protocols (and the underlying SNA protocols) for different chain-response types and secondary session request modes.
The figures show:
For simplicity, all messages are assumed to be flowing on the same PLU session.
In the following illustration, the application successfully sends a Data message.
In the following illustration, the application successfully sends a chain of Data messages.
In the following illustration, the host rejects a chain of Data messages.
In the following illustration, the host rejects the first definite-response chain and rejects the third exception-response chain on a delayed request session. Note that the negative response to the third chain implies a positive response to the second chain.
In the following illustration, the local node detects the application's invalid use of ACKRQD without the ECI application flag on a Data message. Note that no data is sent to the host; however, since the error is critical, the local node will send a TERM-SELF message to the SSCP.
