But what about TSO?
TSO has always been able to run with line-mode terminals. I don't know
whether there is an equivalent to NTO on a platform still in production,
but you can still use Telnet for an LU1 session.
-
TSO line-mode, as a primary LU, requires to work with a secondary LU where
both LUs follow the LU type 1 protocols without function management headers.
Actual hardware which implements precisely this protocol specification as a
secondary LU is a 3767 - if you can still find one.
However, a VTAM application program can mimic the behaviour of the 3767 and
this is what the Communications Server (CS) IP component TN3270 server does
when supporting the TELNET "Network Virtual Terminal" (NVT) logical device.
TSO is prepared to work with a slight variation on this protocol definition
which was implemented in order to allow certain start-stop devices -
terminals - also to be a valid partner for TSO line-mode. The bulk of the
adjustment of the start-stop data flow with asynchronous ASCII
devices[1][2], for example, translation between ASCII and EBCDIC, takes
place using the Network Terminal Option (NTO) extension to the Network
Control Program (NCP). Because the communication controller instruction set
does not include a storage move, NTO does not deal with the conversion of
carriage return (CR) and line feed (LF) to the SNA Character String (SCS)
new line (NL) and vice versa.[3] In order to communicate this variation to
the application, TSO in this case, the LU definition requires the operand
TERM=TWX. The characteristic "shows up" when using the INQUIRE macro with
OPTCD=DEVCHAR.[4]
NCP today runs under "Communication Controller for Linux on System z" (CCL).
CCL does *not* support NTO but, from V1.2.1, it does support X.25 NCP Packet
Switching Interface (NPSI). One of the functions supported by NPSI is the
so-called "integrated PAD" or "logical link control" (LLC) type 5. With this
option defined, NPSI will communicate with an Asynchronous ASCII device
using X.29, "downstream", where the device uses X.28 controlled by X.3, and
presents the appearance of an LU supported by NTO "upstream" equivalent to
the Asynchronous ASCII (TWX) support.
Thus, as so often in networking, NTO itself is not supported "on a platform
still in production" but there is "a platform still in production" which
mimics NTO in support of an Asynchronous ASCII device.
Now if you ***really*** have to use a real Asynchronous ASCII device, I
guess that Linux on a z series machine together with CCL, NCP, NPSI and an
OSA feature, a "box" of some sort offering X.25 over TCP/IP (XOT) on one
side and X.25 on the other and a "box" of some sort offering X.29 on one
side and X.28(X.3) on the other - with the possibility that both these
"boxes" could be just one "box" - might be a sensible configuration.
If you have an end-user "box" with any intelligence you are going to use a
TN3270 client program on it.
[1] Identified as "Teletypewriter Exchange (TWX) Service Models 33, 33ASR,
and 35" in the NTO manual.
[2] Other devices are, using NCP device identification terminology, "IBM
2741 Communications Terminal", "IBM 2740 Communications Terminal Model 1"
and "World Trade Teletypewriter Terminals (WTTY)". Note that another device
supported through NTO which is not a candidate for use with TSO is the "IBM
3780 Data Communication Terminal".
[3] The conversion of CR and LF to NL is not quite as simple as may be
thought at first glance. For example, the sequence CR LF LF needs to be
converted to NL <blank> NL because of the SCS rule that an NL immediately
following an NL is ignored.
[4] An equivalent indication is given to VTAM when performing Unformatted
System Services (USS) using the SSCPFM=USSNTO specification on the LU
statement.
Chris Mason
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
