Inbound Chaining

The division of application data into Data messages and the control of inbound chaining are the responsibility of the application.

The secondary maximum send RU size for the session is a parameter in the BIND from the host and is available in the BICB on the Open(PLU) (OK) Confirm message. The application should ensure that each inbound Data message corresponds to a single RU; that is, it does not contain more data than the maximum RU size given in the BICB.

The application should use the BCI and ECI application flags in the Data message headers to control chaining (see Application Flags). The chain is the unit of recovery, and if recoverable errors occur in the chain, then the application should assume responsibility for recovery (see Recovery).

An inbound chain can terminate in the following ways:

• The complete chain is sent without errors; that is, all the Data messages in the chain have been passed to the host. If the session allows the secondary to send definite-response chains, and the application sets the ACKRQD field in the last Data message of the chain, then the application receives a Status-Acknowledge(Ack) from the local node when the host supplies a response.
• The local node detects a critical error in the format of a Data message from the application or in the state of the session. The local node rejects the Data message with a Status-Acknowledge(Nack-2) containing an error code and closes the PLU connection. Note that the local node will generate an inbound CANCEL request before closing the PLU connection. The local node will send a TERM-SELF request to the host to elicit an UNBIND.
• The host sends a negative response to a request in the chain. The local node sends a Status-Acknowledge(Nack-1) message to the application with the sense codes and sequence number from the negative response. Where the host rejects a request that does not carry the ECI application flag, and the application did not specify the "application cancel," option in the PLU CICB, the local node also generates an inbound CANCEL request. When the application specifies "application cancel," then it must send EC or Status-Control(CANCEL) to terminate the chain. Any subsequent inbound chains are rejected with a noncritical Status-Acknowledge(Nack-2), sense code 0x2002 or 0x2004 (chaining or direction). When the application receives the Status-Acknowledge(Nack-1) message, it should stop sending data after this chain for half-duplex flip-flop sessions because the direction has passed to the host (see Direction).
• The application cancels the chain while sending, by sending a Status-Control(CANCEL) message to the local node. The local node sends a CANCEL request to the host and sends a Status-Control(CANCEL) Acknowledge to the application on receiving a positive response from the host. Responses from the host to requests sent before the CANCEL will generate appropriate Status-Acknowledge messages to the application if the original Data messages had the ACKRQD field set.
• The application closes the PLU connection while sending the chain. The local node sends a Close(PLU) Response to the application. Responses from the host to requests sent before the Close(PLU) message will not generate Status-Acknowledge messages to the application. Note that the local node will also generate an inbound CANCEL request and a TERM-SELF request to elicit an UNBIND.

If the local node detects a noncritical error in the format of a Data message from the application or the state of the session, it does not close the PLU connection. Instead, it rejects the Data message in error with a Status-Acknowledge(Nack-2) containing an appropriate error code. No data is sent to the host.

If an inbound chain terminates with an error, then if the session uses half-duplex protocols, the application must assume a receive state (see Recovery).

The following six figures illustrate inbound chaining protocols between the local node and the application, and how those protocols relate to the underlying SNA protocols.

In the first illustration, a complete inbound chain is sent without error and accepted by the host; note that after receiving Status-Acknowledge(Ack) the application relinquishes direction to the host.

In the following illustration, the local node detects a critical error in the format of the second Data message in the chain (ACKRQD without the ECI application flag), sends a Status-Acknowledge(Nack-2) to the application with the appropriate error code, and closes the PLU connection. Note that the local node only generates the CANCEL where the session's FM profile supports CANCEL.

In the following illustration, a complete inbound chain is sent without error, but is rejected by the host; after the negative response, the application must enter receive state, pending error-recovery (see Recovery).

In the following illustration, the application cancels the chain by sending Status-Control(CANCEL); note that the application still has direction and can start a new chain.

In the following illustration, the application closes the PLU session while sending the chain; the local node only generates the CANCEL where the session's FM profile supports CANCEL.

In the following illustration, the local node detects a noncritical error in the format of the second Data message in the chain and sends a Status-Acknowledge(Nack-2) to the application with the appropriate error code.