SNAX/HLS Configuration and Control Manual

Step 3. Planning Session BINDs
Planning the SNAX/HLS Environment
2–6 104705 Tandem Computers Incorporated
Planning Codeset
Translation
The natural codeset for the Tandem system is ASCII. If the device can use the ASCII
codeset, it might save computation resources to do so. If, however, the device (or host)
must use EBCDIC code, either the application must work in the EBCDIC codeset, or
conversion must be performed. Code conversion can be accomplished either by
SNAX/XF, or by SNAX/HLS. To cause SNAX/XF to perform the conversion, specify
the attribute CHARACTERSET EBCDIC when configuring the LU through CMI or
SCF, and specify the TRANSLATE attribute as NO in the session PROFILE. To cause
SNAX/HLS to perform the conversion, specify the attribute CHARACTERSET ASCII,
and specify the TRANSLATE attribute as YES in the session PROFILE. Take special
care not to specify codeset translation in both the Tandem SNA access method and
SNAX/HLS. SNAX/HLS cannot determine whether this is occurring, and the
application program will see garbled text.
Although both methods of translation produce identical results and consume
comparable computation resources, there are specific advantages to using SNAX/HLS
to perform the translation:
The translation attribute can be changed during the session.
HLSTAP can format trace information, automatically adjusting for the codeset in
effect at the time of the data transfer.
Correct SNAX/HLS treatment of FMHs.
Switched-Line Attributes It is sometimes beneficial to use switched lines (that is, dial-in and dial-out lines).
SNAX/XF supports dial-in lines and allows both manual and automatic answering.
Support for dial-out is limited to manually initiated calls.
SNAX/HLS supports switched lines by awaiting a modem connect before initiating
traffic on a line. Although this support is transparent, you must specify the
SWITCHED attribute when the line is configured.
The delay for modem connect can be inhibited by use of the OMIT-MODEM-WAIT
attribute in the PROFILE. When selected, the attribute causes SNAX/HLS to attempt
to establish the session without delaying. If the line happens to be inoperative, the
session establishment will fail.
Step 3. Planning
Session BINDs
The goal of this subsection is to provide information needed to plan BINDs suitable for
supporting LU-LU sessions. BIND messages are SNA-defined messages that are sent
to SNA devices but received from SNA hosts.
In device planning, the goal is to select a BIND that specifies the device’s behavior.
In gateway planning, the goal is to specify a BIND that is consistent with the host
product’s behavior, that follows SNA protocol, and that is consistent with
application requirements.
The behavior of SNAX/HLS is almost entirely driven by the session BIND. For a
given session, the result of a SNAX/HLS verb depends on the BIND in effect for that
session; another BIND can cause a different result.