The TCP/IP Connection
Under the Windows NT network architecture, you can normally satisfy your connectivity needs--including any necessary IBM connectivity--using the TCP/IP method. With NT, you can run native file, print, and server-based applications services over TCP/IP. NT includes the basic utilities, such as Telnet for terminal access and File Transfer Protocol (FTP) for data transfer, to facilitate connectivity to UNIX and other TCP/IP hosts. NT can also accommodate third-party TCP/IP applications, including those that implement TCP/IP services for IBM hosts.
Connecting to IBM hosts using this method is technically challenging. TCP/IP was designed for ASCII-based, character-oriented hosts; IBM hosts operate in an EBCDIC-based, block-mode environment. However, one solution that has endured the test of time is Telnet 3270 (TN3270), a special implementation of Telnet that brings block-mode capabilities and EBCDIC-to-ASCII translation to the client system. As the name implies, TN3270 was designed for mainframe connections and has been in use for more than a decade.
On the mainframe side, TCP/IP can be implemented on the host and then connected to the LAN through an IBM 3172 Interconnect Controller. Or an operator can use a TCP/IP-to-SNA gateway as a front end to the mainframe to translate the TCP/IP traffic into native SNA traffic. (For a schematic representation of both approaches, see Figure 3.) A number of vendors supply single-function TCP/IP-to-SNA gateways, including OpenConnect, Apertus, and McData.
TN3270 solves the majority of problems associated with Telnet-to-mainframe access. For example, when a data-entry screen is sent to the TN3270 client from the mainframe, you can access the fields on the screen locally; you can tab back and forth among them to input or change information. No data is transmitted to the host until you press Enter. This is in dramatic contrast to "regular" Telnet, which transmits each and every keystroke you make. TN3270 also supports various screen attributes, such as bright, blinking, underlined, and reverse video, so the screens look relatively normal when they are displayed through TN3270.
All things considered, TN3270 is a more than adequate solution for access to a mainframe over a TCP/IP network. TN3270 has, however, been plagued by one major drawback: It doesn't support printer emulation. This limitation is being addressed through a revised definition of TN3270 termed "TN3270E." Products supporting TN3270E are just beginning to enter the market.
On the AS/400 side, TN3270 is also a solution, albeit not a particularly good one. Specifically, the AS/400 implementation of TCP/IP can accept and process TN3270 traffic, but the differences between the mainframe-oriented 3270 and AS/400-oriented 5250 make using TN3270 awkward, just as using a "real" 3270 on the AS/400 is awkward. To address this problem, an alternative form of Telnet was developed to implement the feature set of the 5250 workstation. This implementation is called Telnet 5250 (TN5250).
Connectivity between a TN5250 client and an AS/400 is a straightforward end-to-end connection over a LAN (see Figure 4). Unlike the mainframe environment, the AS/400 implementation of TCP/IP doesn't require any external devices to handle the network attachment.
Another difference between the AS/400 and the mainframe is that the AS/400 doesn't have local printing; all print operations, even those generated by pressing the Print key on a 5250 workstation, are processed through the AS/400 print-spool facility. Thus, print operations in the AS/400 environment are handled through the TCP/IP Line Print Daemon (LPD) and Line Print Remote (LPR) services.
Those vendors who have native Windows NT implementations of TN5250 or TN3270 client software are shown in the table. Support for TN5250 or TN3270 isn't limited to native NT programs because the NT TCP/IP implementation is compatible with the 16-bit Windows implementation of Windows Sockets for TCP/IP (WinSock). Thus, many of the existing 16-bit Windows implementations of TN5250 and TN3270 can use NT's underlying TCP/IP stack.
Using TCP/IP as the sole network protocol greatly simplifies the construction, expansion, and maintenance of a network. This approach does, however, have two limitations. First, running TCP/IP on an IBM mainframe or an AS/400 usually introduces additional overhead. Second, if you use legacy LAN servers, such as Novell's NetWare 2.x or 3.x, you may not be able to run TCP/IP as the sole protocol on your network. In this case, it would be more advantageous to run Novell's Internet Packet eXchange (IPX) as the sole protocol. Both of these limitations are addressed by the third approach to IBM connectivity: Microsoft SNA Server.
SNA Server--The Microsoft Approach
The final IBM-to-NT connectivity alternative is Microsoft SNA Server. This approach differs dramatically from MSDLC and TCP/IP. In this case, the network protocol employed on the Windows NT client side of the equation can differ from the one used on the IBM host. SNA Server translates between the two protocols.
For the NT client, using SNA Server is similar to using MSDLC. You choose the appropriate software for the function you need: for example, 3270 workstation and printer emulation to attach to an IBM mainframe or 5250 workstation emulation to connect to an AS/400. Instead of communicating with the MSDLC protocol layer, the client-side software communicates with SNA Server using client-side Application Programming Interfaces (APIs).
SNA Server supports a variety of API sets, including:
- Advanced Program-to-Program Communications (APPC): This set is used for a wide range of AS/400 client/server connections (including workstation emulation). It is also used for direct communications between client and mainframe programs.
- Common Programming Interface for Communications (CPI-C): This is a subset of the APPC API set and is used for communications between client programs and mainframe or AS/400 programs.
- Common Service Verbs (CSV): This is a set of APIs for communicating with NetView, IBM's SNA network management solution.
- Logical Unit API (LUA): This set supports APIs for access to LUs 0, 1, 2, and 3, used for client/server connections to mainframes, including workstation and printer emulation.
- 3270 Emulator Interface Specification (EIS): This API set accommodates 3270-emulation packages. Some 3270 emulators use the LUA set instead.
When the NT client-side software (i.e., the 3270 or 5250 emulator) communicates with the applicable set of APIs, the software operates as if it were in an SNA environment. In truth--and this is the beauty of the SNA Server solution--the Microsoft APIs repackage the SNA traffic for transport by IPX, TCP/IP, NetBEUI, or any other NT network protocol. Thus, the traffic generated by an IBM 3270-emulation package can travel over the network as IPX traffic.
Once the traffic reaches SNA Server (see Figure 5), that package extracts the SNA traffic and feeds it to the IBM host as if it were native SNA traffic. The physical connection between SNA Server and the IBM host can be any of the following:
- Token Ring or Ethernet LAN (The SNA Server-to-IBM host connection can be a separate LAN from the client-to-SNA Server connection, or all traffic can flow over a single LAN.)
- Synchronous Data Link Control (SDLC) or X.25 Qualified Logical Link Control (QLLC) links for wide-area connections
- Coaxial (mainframe) or twinaxial (AS/400) connections for attachment via local workstation controllers
- Channel attachment (For a direct high-speed link to a mainframe processor, traditional "bus and tag" and fiber channel connections are available.)
Those vendors who have native NT client software that communicates with SNA Server are listed in the table. Just as MSDLC and WinSock provide compatibility with 16-bit Windows and some DOS clients, the API sets supported by SNA Server are backward-compatible with many existing DOS and 16-bit Windows IBM-connectivity packages. Furthermore, the client-side APIs for SNA Server are available for both DOS and Windows environments.
This degree of compatibility means:
- Existing IBM connectivity software may be able to operate on an NT client and access SNA Server.
- Windows 95, WFW, Windows 3.x, and DOS clients can use SNA Server for IBM host access.
SNA Server gives you the freedom to choose whichever LAN protocol is best suited to your client-side network. It also lessens the connectivity burden on IBM hosts, increases the security of host connections, and provides an easy-to-use administration interface for client and host connections. These benefits normally outweigh the costs associated with implementing SNA Server.
The Right Solution
Does this mean that SNA Server is right for every solution? Not exactly. Clearly, SNA Server is well-suited for many IBM-connectivity applications, but there is no such thing as "one size fits all." MSDLC is more suitable for small networks, and a TCP/IP solution is a better fit for environments where each host, including IBM's, supports TCP/IP network services. The bottom line is: Look at all your options, and select the best fit for your own network needs.
Other Native Windows NT SNA Software for the SNA Server
(Products marked with * may still be under development.)
AIP SNAPPI (Middleware)
Data Connection DSNX/E (NetView client)
Dr. Materna GmbH
* SDX for Windows NT (3270 and
IPDS printer emulation)
* IPDS for Windows NT (IPDS printer emulation)
* Print/400 for Windows NT
(IPDS printer emulation)
gkd Printeam * PrintPass
(AFP/IPDS printer emulation)
IBM UK Laboratories CICS for Windows NT
(Transaction processing)
Information Builders
EDA/Link Gateway for Windows NT
(Database gateway)
EDA Open Database Gateway for Windows NT
(Database gateway)
Interface Systems Oasis (AFP printer emulation)
KnowledgeNet NetWrk/NT (Middleware)
Micro DecisionWare
DB Gateway for MVS, Windows NT
(Database gateway)
DB Gateway for DB2-DRDA, Windows NT
(Database gateway)
DB Gateway for AS/400-DRDA, Windows NT
(Database gateway)
DB Gateway for SQL/DS-DRDA, Windows NT
(Database gateway)
MicroGate 2780/3780 emulation
(Combined hardware/software product)
NetSoft NS/Print Server for Windows NT
(Mainframe print integration)
Neon Systems Shadow ODBC Direct
(Database gateway)
Passport Communications
Host RJE Exchange (Mainframe file transfer)
Host Print Exchange (Mainframe print integration)
Proginet
IND$FILE Plus (Mainframe file-transfer add-on)
Fusion (Mainframe file transfer)
Showcase
Showcase Data Distributor (Database gateway)
Siemens Nixdorf
* TRANSIT (3270 and IPDS printer emulation)
StarWare StarSQL (Database gateway)