The Digital Connection, Part 2

Although terminal access is certainly an important component in any host-based network (see, "The Digital Connection, Part 1" in the March issue of Windows NT Magazine), it's not the only consideration. When you introduce PCs or Windows NT Workstations into a network, your need for host-connectivity services typically expands to include file transfer and more advanced network services, such as directory and file sharing, printer sharing, and program-to-program communications. Let's take a look at how these non-terminal services come into play in Digital Equipment's networks.

The network services available in Digital's TCP/IP networks are remarkably similar to those in most UNIX-based TCP/IP networks. Specifically, you can use the Telnet protocol for terminal access, the File Transfer Protocol (FTP) for file transfer, the Network File Services (NFS) protocol for directory and file sharing, the Line Printer Daemon/Line Printer Requester (LPD/LPR) protocol for printer sharing, and old-fashioned TCP/IP sockets (i.e., Berkeley sockets) for program-to-program communications. The TCP/IP suite of protocols and services is available for all of Digital's commercial operating systems, including Digital UNIX, OpenVMS, Ultrix (a Digital UNIX precursor), and even Digital's "closed" VMS operating system.

At one time, Digital didn't support TCP/IP under VMS and offered its proprietary DECnet suite of protocols and services instead. The DECnet suite is a well-rounded, robust architecture for implementing distributed processing and client/server applications. The combination of VMS and DECnet was strategically important to Digital when the company was competing against IBM's host-centric mainframe architecture. Instead of selling processor or central resource upgrades to give customers more power (the IBM approach), Digital sold customers another computer to go on their networks.

DECnet shares a number of similarities with TCP/IP--as VMS shares a number of similarities with UNIX--but DECnet also provides some unique advantages in several key areas.

• Terminal Access--The only official DECnet component for terminal access is the Command TERMinal (CTERM) protocol, which allows a terminal logged on to one system to initiate a logon to another system. The initial connection between a terminal and a Digital host can be via a serial connection or via the Local Area Transport (LAT) protocol if a terminal server is used (but neither of these connections is deemed to be part of DECnet).
• File Transfer--DECnet has two popular solutions for file transfers between systems. One simple solution is to use a COPY command in conjunction with Digital's network-wide file-naming structure. The other solution is the Network File Transfer (NFT) utility, an interactive facility similar to FTP. NFT runs on the client side of the transfer and communicates with a background service known as the File Access Listener (FAL) on the server.
• File Sharing--Cross-system file sharing is one of the strong points of DECnet. This strength is due to the fact that support for this service is built into VMS--it's not a separate set of utilities and protocols, as it is in NFS. Under VMS/DECnet, if you want to open a file on another system, you simply include a full file reference in your command or program. This reference identifies the hosting node, a user ID to use for the access, the directory--and subdirectories--in which the file resides, and the filename. The only drawback to this approach is that full file references can be quite long and complex.
• Printer Sharing--Printing in the DECnet environment is host-driven; however, the printers themselves can reside anywhere on the network. Each host has a number of print queues to manage, and each queue can be associated with a local printer, a network printer, or a queue on another Digital host. From a broad perspective, the DECnet approach to printing is similar to UNIX's handling of local and network printing via the LP and LPR/LPD facilities.
• Program-to-Program Communications--DECnet is rich in services in this area. DECnet supports a variety of communications interfaces, ranging from a simple, socket-like interface, the DECnet task-to-task interface, to a complex, queue-oriented interface with guaranteed delivery--with several variations in between.

DECnet services originally were geared toward peer-to-peer communications between Digital hosts. When PCs arrived on the scene, Digital and Digital connectivity vendors had to devise new solutions for integrating PCs into DECnet networks.

The Demanding Desktop
The first approach to PC-to-Digital connectivity was to bundle simple modem-transfer protocols with terminal-emulation software. These protocols included Kermit, Xmodem, Ymodem, and eventually Zmodem, but Kermit was by the far the most popular. Some Digital connectivity vendors such as Walker, Richer & Quinn (WRQ) also developed their own proprietary file-transfer protocols for inclusion with their terminal-emulation software. Although this approach was limited in scope, it was an effective solution for a variety of applications. It's still used frequently today.

As PCs became more sophisticated, demands for more sophisticated PC-to-Digital connectivity tools increased. Digital responded by developing a product called DECnet-DOS that delivered many--but not all--of DECnet's capabilities to the PC environment. In time, DECnet-DOS evolved into a product called Pathworks, which quickly became Digital's flagship product for connectivity to its networks from DOS, Windows, OS/2, and Macintosh workstations.

At first, Pathworks was a DECnet-oriented product that provided the following services:

• Terminal emulation transported over the LAT and CTERM protocols
• File transfer using the NFT/FAL model--Pathworks included both the client (NFT) and server (FAL) components
• Printer sharing to enable workstations to access DECnet printers as virtual printers and to allow workstation-based printers to function as DECnet printers
• File sharing accommodated by the use of both client-side and host-resident software--the host-side software allowed a Digital host to appear as a LAN Manager (NetBIOS/Server Message Blocks (SMB)) server using DECnet as the transport protocol (as opposed to using the traditional LAN Manager transport protocol, NetBEUI); the client-side software included a modified version of Microsoft's LAN Manager software to enable file sharing over DECnet (Pathworks' approach to file sharing was very different from file sharing between Digital hosts in a DECnet network)
• Support for programs that used DECnet task-to-task communications--Pathworks didn't include tools to develop these programs; Software Development Kits (SDKs) were sold separately

As TCP/IP became more popular--or from Digital's perspective, as DECnet became less popular--Digital expanded Pathworks to include TCP/IP capabilities (e.g., Telnet and FTP), NetBEUI support for Pathworks connections, and support for NetWare protocols and services (including host-side software that emulates a NetWare server instead of a LAN Manager server). All the original capabilities listed are still available in the LAN Manager version of Pathworks.

The Transition to NT
Given Digital's investment in the future of Windows NT technology, you would think that the company would have developed a robust version of Pathworks for the NT environment. Although it has to a certain extent, Digital also has taken the opportunity to weed out some of the protocols and services it wasn't particularly fond of. Therefore, if you look at the capabilities of Pathworks for Windows NT, you will find that it offers:

• File transfer using NFT/FAL
• Virtual printing to DECnet printers
• The client-side of shared file access (NetBIOS/SMB) using the DECnet protocol
• Support for task-to-task communications (but with no development environment)
• The ability to share NT file, print, and application services over DECnet if you're running Windows NT Server (in effect, Windows NT Server becomes a Pathworks server)

Notice anything missing from this list? Pathworks for Windows NT does not include the two native terminal-transport protocols, CTERM and LAT. These two protocols are Digital's least favorite--for a variety of reasons--and have not been ported to NT. If you want terminal access to Digital hosts, you need to use Telnet or employ a third-party package. (A list of third-party vendors appears with my March column, as well as more information on CTERM and LAT.)

Viable and Welcome
Despite the absence of CTERM and LAT, Pathworks for Windows NT is a viable and welcome member of the Pathworks family of products. Furthermore, although Digital is clearly moving away from DECnet and proprietary network implementations, Pathworks remains Digital's premiere client/server connectivity solution. It will most likely be around until the last DECnet network is shut down and dismantled. And that's likely to be a long time from now.