SNAX/HLS Configuration and Control Manual

Temporary UNBIND
Interpreting SNA Protocol
7–2 104705 Tandem Computers Incorporated
Temporary UNBIND When SNAX/HLS receives an UNBIND request (with type code 02), it does not
terminate the session with respect to the application. This can occur when beginning a
TSO session. SNAX/HLS keeps all resources allocated while anticipating the
promised BIND command. If the application has enabled BIND and CINIT messages,
it receives two such messages (one for the initial BIND and one for the second BIND).
Treatment of Flow
Controls
Upon receipt of an RTR message, SNAX/HLS always returns a negative response with
sense code %H0819 (nothing to send). Upon receipt of any other legal flow control
message (QEC, QC, BIS, SBI or RELQ), SNAX/HLS responds positively if the
receiving half-session has enabled receipt of flow control messages; otherwise, it
responds with sense code %H1003 (function not supported).
If, however, a storage problem is preventing the receipt of the message, the response is
always %H0812 (insufficient resources).
Correlation Tables SNA requires that a correlation-table entry be created and retained for every outgoing
chain. Entries are removed from the table only when the response is received or
implied. Unfortunately, if exception-response chains are heavily used, the table can
become enormous. SNAX/HLS, therefore, does not retain correlation entries for
exception-response chains. Consequently, certain error situations cannot be
diagnosed. For example, if an uncorrelated negative response arrives, SNAX/HLS
assumes it belongs to a previously issued request and forwards the message to the
user as a RC-REQUEST-REJECT. An uncorrelated positive response is treated as a
protocol violation.
RU Tests SNAX/HLS exhaustively tests each incoming RU (as prescribed by SNA protocol). In
addition, an incoming DFC message is tested to see if it corresponds to one of the
requests defined in the formal protocol. Undefined requests cause a negative response
with a sense code of %H1003 (function not supported). This treatment is consistent
with that of IBM’s VTAM.
Purging Chains When a negative response is sent while in the process of receiving a chain, the
remainder of the chain must be discarded, up to and including the end-of-chain or the
CANCEL message, whichever arrives first. To accomplish this, the
FSM_CHAIN_RCV enters the PURGE state when a negative response is sent, and
returns to BETC only after receiving either the end-of-chain or a CANCEL message. A
presumed error in the protocol specification causes this function to work improperly.
SNAX/HLS re-interprets the protocol specified in the DFC.RCV procedure on page 5-
50 of the IBM SNA Format and Protocol Reference Manual, and reverses the order of
calling the RCV_DISCARD_CHECKS procedure and the RCV_FSMS procedure for
normal received requests.