File Transfer, File Sharing, Printer Sharing, and Program-to-Program Communications
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.
End of Article
Register
