SNAX/HLS Application Programming Manual

HLS-FLOW-CONTROL Verb
SNAX/HLS Verbs
104707 Tandem Computers Incorporated 5–25
HLS-FLOW-CONTROL
Verb
This specialized SNA verb, which presumes a fairly detailed knowledge of SNA,
allows you to send one of four different flow control messages to your partner. Three
messages deal with the initiation of messages, and one deals with the initiation of
transactions.
Table 5-1 shows the SNA messages that correspond to this verb.
Table 5-1. SNA Messages for HLS–FLOW–CONTROL Verb
SNA Message Verb Argument Meaning
RTR RT Resume sending transactions
QEC SM Stop sending messages (that is, a request)
QC QM Message sending quiesced (that is, a confirmation)
RELQ RM Resume sending messages
The formal SNA definitions restrict the use of these messages to particular partners
and to particular session types. If your use of these commands would violate the SNA
rules, the message is not sent and the reply indicates RC–SEND–CHECK.
If your session sends the SM (Stop Sending Messages) request, SNAX/HLS
automatically allows your session to receive flow control messages. This is provided
as a convenience to the programmer; if the receipt of flow control messages were not
enabled, your application could never detect the QM reply.
Note that this automatic enabling of the receipt of flow control messages occurs only
on the SM request.
The detailed information about each message is as follows:
Resume Sending Transactions (RT)—This variant directs SNAX/HLS to send an
SNA RTR request to the session partner. RTR is a message defined by SNA that is
used only when brackets are in use. SNA permits brackets (also known as
transactions) to be initiated by only one of the session partners (known as the first
speaker). If the protocol permits transactions to be initiated by the other side
(known as the bidder), it must bid for the brackets, either by issuing a special SNA
BID message, or by trying to start a transaction and tolerating a reject.
The first speaker can issue this RTR to grant permission to the Bidder to begin a
transaction, or to find out if the bidder wishes to begin a transaction. A positive
response to the RTR indicates that the bidder initiates the next transaction. If the
bidder does not want to initiate a transaction, it issues a negative response.
Use of this request requires a detailed knowledge of the protocol between the
session partners. It should not be used carelessly.
A typical use of this message is when your application has assumed control of
bracket rejects (PROFILE specifies USER for the BID–REJECTION attribute). At
some earlier point your application has received a DT–BID–REJECTED message.