SNAX/HLS Configuration and Control Manual

Step 4. Planning the Application Environment
Planning the SNAX/HLS Environment
2–22 104705 Tandem Computers Incorporated
Receipt of these messages can be enabled two ways: The attribute can be set in the
PROFILE, or your application can issue the SM message using the
HLS-FLOW-CONTROL verb.
If your half-session is not enabled for flow control messages, the SNAX/HLS server
rejects any of the above messages from your partner with sense code %H1003.
However, in the case of RTR, the SNAX/HLS server always responds with %H0819,
because the SNAX/HLS server has no way to determine whether any brackets are
ready to send.
Pipeline LU
Pipeline LUs allow multiple application requesters to access the same session. To
avoid chaos, this feature is limited to a situation where all the applications are
equivalent, context-free servers and are normally awaiting input. Any message they
receive can be answered in one response. Correlation of request and response is an
application responsibility.
Bracket Bid Rejects
SNAX/HLS supports three distinct treatments of the situation where the first speaker
decides to reject a bid from the bidder. These three distinct treatments (selected by the
BID-REJECTION PROFILE attribute) are described in the following subsection.
NO-RTR: Reject With 0813. This response to a BID (or a begin-bracket RU) is generated
automatically by SNAX/HLS. The bidder has no choice but to retry the bid at some
future time. The first speaker will not necessarily prompt the bidder. The local
application is unaware of the occurrence of this event.
AUTO: Reject With 0814, RTR generated automatically. This response to a BID (or a begin-
bracket RU) is generated automatically by SNAX/HLS. When the session is next
between brackets, SNAX/HLS generates an RTR request. The local application is
unaware of the occurrence of this event.
USER: Reject With 0814, tell local application. This response to a BID (or a begin-bracket
RU) is generated automatically by SNAX/HLS, and a DT-BID-REJECTED message is
sent to the application. Your application is responsible for generating the RTR when
appropriate.
The NO-RTR attribute recreates the behavior of versions prior to C10 of SNAX/HLS
and is the default attribute. If you choose this attribute be aware that the bidder may
have no choice but to retry the bids at a frequent rate, thus misusing the
communications line.
If the AUTO attribute is used, a potential race condition can occur if your application
begins a bracket immediately after the end of a previous bracket. In this environment,
the session is between brackets and SNAX/HLS generates the RTR. Simultaneously,
your application issues a SEND-DATA. Your partner may receive an RTR, send the
BID and receive a reject to the BID. Although this behavior is permissible, it is
undesirable.