The Digital Connection

Digital Equipment has had its share of ups and downs during the last five years. On the down side, Digital's premiere VMS operating system and highly touted DECnet network architecture fell from the top of the heap of preferred technology. They are now regarded as "old" technology. On the up side, Digital released its Alpha line of RISC computers; it committed to open networks (e.g., TCP/IP) and open operating systems (e.g., Digital UNIX and OpenVMS); and it embraced Windows NT with open arms.

As a result, Digital is now firmly rooted in two different network architectures: DECnet and TCP/IP. Although you can clearly make the case that DECnet is fading fast, the sheer number of existing installations will carry it into the future. After all, it was a widely respected network architecture for years, and plenty of DECnet bridges and routers are in operation around the world to prove it.

Although Digital may secretly wish to be free from the burden of supporting two network architectures, its official position is to offer its customers a choice between DECnet and TCP/IP. Every non-Intel (non-PC) system offered by Digital supports both DECnet and TCP/IP. This support reaches across all hardware-platform and operating-system combinations. CISC-based VMS systems, MIPS-based Ultrix systems, and Alpha-based Digital UNIX, OpenVMS, and NT systems can all run either DECnet or TCP/IP, although in some cases you must pay more for one of them.

The availability of TCP/IP support across the Digital product line is good news for NT users. It means they can use the standard TCP/IP tools included with NT to interact with Digital computers: Telnet for terminal emulation, FTP for file transfer, and LPR/LPD for print sharing. One limitation of this approach, however, is that the NT Telnet application doesn't support the full range of Digital terminal types. A second, more obvious limitation is that it doesn't work in a DECnet environment. Let's take a look at both of these issues from the perspective of terminal access.

Digital Terminals
Digital terminals are character-oriented devices that transmit each character as it's being typed and then wait for it to be echoed by the host before displaying it on the screen. This gives the application program complete control over the terminal; however, it also generates a fairly large amount of network traffic.

Digital's first terminal was the VT52; however, the VT52 is not ANSI-compliant, and therefore, it's rarely used these days. Digital's first ANSI-compliant terminal line was the VT100 family, introduced in 1978. The VT100 line was then replaced by the VT200 line, which introduced an editing keypad to the terminal keyboard, resulting in a layout that's very similar to today's 101+ key PC keyboards. The VT200 was replaced by the VT300 line, which was, in turn, partially replaced by the VT400 line.

The Digital VT terminal lines can be further categorized as models that support bitmapped graphics (VT125, VT240, VT241, VT330, and VT340) and those that operate only in monochrome character mode (VT101, VT102, VT220, VT320, and VT420). With the exception of the VT101, all the character-mode terminals can switch back and forth between 80- and 132-column operations; the VT101 is limited to 80 columns.

Digital's line of bitmapped terminals includes both monochrome and color models. The VT family's graphics format is called the Remote Graphics Instruction Set (ReGIS); it is proprietary to Digital. As a result, very few Telnet implementations provide terminal emulation supporting ReGIS; in fact, most Telnet implementations emulate the VT101, VT102, or VT220--NT emulates the VT101.

Support for VT10x/VT220 emulation is often sufficient to satisfy the requirements of Digital applications. In some cases, however, you may need graphics support or support for some of the minor improvements introduced with the VT300 and VT400 lines (e.g., an extra status line or more flexible programmable keys). In these cases, you must turn to third-party terminal-emulation companies that offer high-end terminal-emulation software for NT (see table 1).

The products available from these companies can operate over several different data-communications or network interfaces. In the NT environment, VT terminal-emulation software can:

• Operate as Telnet programs using the NT TCP/IP protocol stack.
• Communicate over a serial connection to a terminal server.
• Communicate over a direct serial connection to a Digital host computer.
• Communicate via a third-party protocol that emulates the Digital protocol used by terminal servers.

Using TCP/IP to connect to Digital hosts is as simple as using any Telnet program. The other options, however, require more explanation.

Terminal Servers
Although all Digital terminals are equipped with serial connections, they aren't usually connected directly to a host computer. Instead, they are usually cabled to a terminal server, which is, in turn, connected to a LAN (usually Ethernet). A simple command interface on the terminal server enables each terminal to select the host it wants to connect to and to toggle among multiple host connections.

Terminal servers come in two varieties: The first uses Telnet to initiate host connections and is targeted for TCP/IP networks; the second uses the Local Area Transport (LAT) protocol and is mostly found in DECnet environments, although you will occasionally find it in TCP/IP environments. (LAT is not officially part of the DECnet suite of protocols and services; it is a separate specification.)

LAT suffers from two significant drawbacks: It doesn't support network addresses and, therefore, must be bridged instead of routed in WANs; and it's a timing-sensitive protocol that can cause problems in large or high-volume networks. As a result, Digital is reluctant to implement LAT in new products.

One fallout of Digital's reluctance to use LAT affects the NT environment. Specifically, the company hasn't committed to developing LAT drivers for NT. However, several third-party companies have developed their own LAT drivers for NT (see table 2). A combination of a third-party LAT driver with a third-party terminal-emulation package lets a NT system emulate a terminal server sponsoring a number of individual terminal connections.

This situation raises the question: If LAT is so bad that Digital doesn't want to implement it anymore, why should anyone want to use it? Like DECnet, LAT has been around for a long time, and lots of companies have constructed networks around its good and bad points. In these companies, LAT is the preferred terminal-transport protocol.

Another much more practical reason for NT users to use it is that LAT and TCP/IP are the only two choices available for LAN-based terminal transport. Although DECnet includes a routable terminal-oriented protocol (the Command Terminal, or CTERM, protocol, also known as the SET HOST protocol), Digital has elected not to implement it in the NT environment, and, unfortunately, no independent companies have stepped in with their own implementations. So if you're not running TCP/IP, LAT is currently your only choice.

Digital and other third-party companies provide implementations of LAT and CTERM for DOS and 16-bit Windows environments. However, many of them don't function in the NT environment.

Is Terminal-Emulation Enough?
Using TCP/IP or LAT with third-party terminal-emulation software provides an environment comparable to--if not actually better than--the environment provided by "real" VT terminals. In many cases, terminal access is only one of the considerations for workstation-to-host interconnections. For example, many DECnet environments require printer sharing, file transfer, dynamic file sharing, and program-to-program application programming interfaces (APIs). Similarly, some environments require integration with Digital's PC-to-host integration product, Pathworks. How do these capabilities fit into the NT picture? Tune in to my next column for part 2 of this pulse-pounding story.

End of Article