The Digital Connection

Digital Offers Its Customers a Choice Between DECnet and TCP/IP

Digital Equipment has had its share of ups and downs during the last fiveyears. On the down side, Digital's premiere VMS operating system and highlytouted DECnet network architecture fell from the top of the heap of preferredtechnology. 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); andit embraced Windows NT with open arms.

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

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

The availability of TCP/IP support across the Digital product line is goodnews for NT users. It means they can use the standard TCP/IP tools included withNT to interact with Digital computers: Telnet for terminal emulation, FTP forfile 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 ofDigital terminal types. A second, more obvious limitation is that it doesn'twork in a DECnet environment. Let's take a look at both of these issues from theperspective of terminal access.

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

Digital's first terminal was the VT52; however, the VT52 is notANSI-compliant, and therefore, it's rarely used these days. Digital's firstANSI-compliant terminal line was the VT100 family, introduced in 1978. The VT100line was then replaced by the VT200 line, which introduced an editing keypad tothe 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 thatsupport bitmapped graphics (VT125, VT240, VT241, VT330, and VT340) and thosethat operate only in monochrome character mode (VT101, VT102, VT220, VT320, andVT420). With the exception of the VT101, all the character-mode terminals canswitch back and forth between 80- and 132-column operations; the VT101 islimited to 80 columns.

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

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

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

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

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

Terminal servers come in two varieties: The first uses Telnet to initiatehost connections and is targeted for TCP/IP networks; the second uses the LocalArea Transport (LAT) protocol and is mostly found in DECnet environments,although you will occasionally find it in TCP/IP environments. (LAT is notofficially part of the DECnet suite of protocols and services; it is a separatespecification.)

LAT suffers from two significant drawbacks: It doesn't support networkaddresses and, therefore, must be bridged instead of routed in WANs; and it's atiming-sensitive protocol that can cause problems in large or high-volumenetworks. 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 forNT (see table 2). A combination of a third-party LAT driver with a third-partyterminal-emulation package lets a NT system emulate a terminal server sponsoringa number of individual terminal connections.

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

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

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

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