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:

• Windows NT Microsoft Data Link Control (MSDLC) network protocol
• Windows NT Transmission Control Protocol/Internet Protocol (TCP/IP) network protocol
• Microsoft SNA Server

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.