SNA Connectivity Solutions

SNA Connectivity Solutions

During the last few years, several operating systems have competed for control of the corporate desktop. Gaining control, however, often means accommodating connectivity to IBM mainframes or AS/400 computers. Now that Windows NT is seriously vying for desktop space, many corporations are taking a hard look at how the NT environment addresses connectivity. This article focuses on the three "native" NT facilities for IBM connectivity:

All three of these facilities require LAN connections. Windows NT Magazine will explore options for wide-area connectivity, as well as non-Microsoft IBM connectivity solutions, in future issues.

MSDLC--The IBM Approach
The MSDLC protocol is Microsoft's implementation of a core component of IBM's Systems Network Architecture (SNA): Data Link Control. DLC manages end-to-end communications between two IBM devices or systems on a network. Its functionality includes error detection and correction, as well as low-level security validations, to confirm that the connecting devices are authorized to communicate.

DLC operates above the physical control layer, so it's not tied to any specific network interface. Thus, DLC is not only a component of LAN-based IBM communications but also plays an important role in wide-area connections. For example, the Synchronous Data Link Control (SDLC) protocol, the Integrated Services Digital Network (ISDN) Data Link Control (IDLC) protocol, and other SNA wide-area protocols each contain a DLC component.

The NT implementation of MSDLC is a LAN-based protocol that operates over Token Ring and Ethernet LANs. From a functional perspective, MSDLC provides services equivalent to the DLC implementations in IBM's DOS-based LAN Support Programs and OS/2-based Communications Manager in its various forms.

MSDLC is of little value by itself because it provides no application or user-level services. To gain value from MSDLC, you must add a layer of software on top of it that provides IBM workstation or controller emulation, implements IBM Advanced Program-to-Program Communications (APPC) services, or provides other IBM-oriented services. The application-oriented services available for MSDLC depend on the type of IBM system involved.

The most common partner for MSDLC in the mainframe environment is software providing Physical Unit (PU) 2.0 service, including 3270 workstation and workstation-controller emulation. (PU 2.0 refers to an SNA device that communicates to a host system as a peripheral node.) The software uses MSDLC to obtain a LAN-based connection to the host computer via a front end, a LAN channel adapter (e.g., the IBM 3172 Interconnect Controller), or a separate workstation controller that supports downstream PU connections (e.g., the IBM 3174). (See Figure 1.)

The majority of PU 2.0 software supports 3270 workstation access and printer emulation, but support for IBM's APPC services is also emerging in the mainframe environment. This allows desktop-based applications to directly communicate with mainframe applications.

The AS/400 environment does not utilize PU 2.0 software for LAN-based connectivity. Instead, it uses peer-oriented PU 2.1 software that also implements IBM's APPC services. (PU 2.1 refers to an SNA device that is an extension of the PU 2.0 node support; a PU 2.1 node communicates as a peer system.) In fact, virtually all LAN-based AS/400 traffic using MSDLC operates over APPC services. This includes workstation (5250) emulation, printer emulation, program-to-program services, and more. MSDLC provides a direct link between two LAN-based systems in the AS/400 arena (see Figure 2); there are no interim connections as there are in the mainframe environment.

Many of the major IBM network vendors provide native NT software solutions that support MSDLC connections (see the table). Support for MSDLC is not limited to NT programs, however. Microsoft originally implemented MSDLC as a DOS-based service for the LAN Manager environment. Subsequent implementations were developed for Windows for Workgroups (WFW) and Windows 95. Thus, legacy DOS and 16-bit Windows applications that support MSDLC can use the NT implementation of it--provided that the applications run in the NT environment.

MSDLC is a tried and true solution for IBM connectivity, but implementing it in an NT environment has significant drawbacks. First, it forces you to support a mixed-protocol LAN, which is inherently more difficult to configure and debug than a single-protocol LAN. Second, MSDLC isn't a routable protocol; it must be bridged. Implementing it in a multiple LAN environment drives up both the cost and complexity of the network because the mixture of routable and non-routable protocols forces you to either use routers that support bridging or implement both routers and bridges.

All things considered, MSDLC is a good solution for simple LAN environments. However, if you're dealing with a complex network, you should take a closer look at the other two approaches.

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:

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:

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:

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)