ch01.htm

this describes managing multivendor networks

<H2><A NAME="Heading11"></A><FONT COLOR="#000077">Application/User Relationship</FONT></H2>
<P>Although Digital offers a variety of different operating systems and hardware
architectures, this section focuses on the most popular combination--the OpenVMS
operating system on Alpha AXP.</P>
<P><I>OpenVMS</I> is an interactive operating system, originally developed for the
VAX, that gives each user the illusion that he or she is the only user on the computer.
Each user can run programs and access files independently of other users. If shared
services are required for access to a common data base, for example, the services
are handled at a system level, invisible to the user. After a user is logged onto
a given computer in the system, the further interaction between that user and the
computer is termed a <I>session</I>.</P>
<P>Within a session, the interaction between the user and the application is typically
character-oriented. Although Digital terminals and programs do support block-oriented
transmission formats for data entry, the application usually reads single (or small
groups of) characters from the keyboard as they are being typed.</P>
<P>For more sophisticated applications such as word processing, this reading method
enables the terminal and the application to interact as a PC keyboard interacts with
a PC--each key pressed can be interpreted as appropriate for that context. (This
similarity is one of the reasons that PC software vendors migrate toward DEC equipment.
Conceptually, they are very similar in intent and implementation.)</P>
<P>Although many other computer systems use a character-oriented, interactive interface
(for example, the HP 3000 under its MultiProgramming Executive, or MPE), Digital
has so refined this interface that it has become an integral part of Digital's applications
development strategy.</P>
<P>Digital has also developed its own graphical interface for terminals and PCs.
This interface, termed <I>DECwindows,</I> provides an alternative interface between
the user and the applications. As X Window graphic terminals become more available,
this method will become the preferred alternative to the traditional character-oriented
interface. DECwindows can be used with the OpenVMS, ULTRIX, and MS-DOS operating
systems.
<H2><A NAME="Heading12"></A><FONT COLOR="#000077">Terminal Attachment Philosophy</FONT></H2>
<P>Terminals can attach physically to the network through one of the following two
devices:

<UL>
	<LI><I>A host.</I> In this case, the terminal attaches directly to a Digital Equipment
	host via an asynchronous link.<BR>
	<BR>
	
	<LI><I>A terminal server (DECserver).</I> The terminal attaches (via an asynchronous
	link) to a specialized device that manages the interface between the physical network
	(ethernet) and the terminal.
</UL>

<P>The simplest connection consists of a terminal directly connected to a Digital
host via a simple, asynchronous line (see Figure 2.4). With this attachment, the
host responds directly to the terminal's activities without using any complicated
protocol. By necessity, the terminal must activate a session on the attached host
to access any local or remote application. The relationship between the terminal
and host is a simple one-to-one connection (one terminal connecting to one host port).</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig04.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig04.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig04.gif"><B>FIG. 2.4</B></A> <I>Direct Attached Terminal</I></P>
<P>In the more normal case, however, terminals connect to terminal servers called
<I>DECservers</I> (see Figure 2.5). Although the interaction between the terminal
and its server is identical to the interaction between the terminal and a directly
connected host (specifically, no complicated protocol is required), the interactions
between the terminal server and the computers are quite different.</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig05.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig05.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig05.gif"><B>FIG. 2.5</B></A> <I>Terminal Server Connection</I></P>
<P>Terminal servers talk to Digital host computers using the LAT protocol. LAT operates
independently from other DECnet protocols and provides two significant benefits:

<UL>
	<LI><I>Group transmission. </I>Under LAT, the terminal server collects characters
	from a terminal and sends them to the host as a group, rather than as individual
	transmissions. LAT transmission is often less disruptive for the computer hosting
	the application and therefore can improve performance.<BR>
	<BR>
	
	<LI><I>Multiple hosts. </I>Because LAT is not associated with any particular host,
	the terminals attached to the terminal server can connect to any of the hosts on
	the same ethernet LAN. In many cases, terminal servers provide a means for a single
	terminal to invoke different sessions on multiple hosts and switch back and forth
	between them.
</UL>

<P>More complicated are the cases in which a terminal directly connected to a host
wants to access another host, or when a terminal on a terminal server wants to access
a host that is not locally attached to the ethernet network but is attached to the
wide area Digital network. In both instances, another protocol, <I>CTERM (Command
Terminal),</I> comes into play. A DECnet host uses the CTERM to shuttle information
between a terminal and another host (see Figure 2.6). The drawback to this technique,
however, is that it consumes resources in the host sponsoring the remote link (that
is, the one initiating the connection).</P>
<P>Regardless of the type of connection, the terminal normally uses the XON/XOFF
mechanism to control the flow of data. With this technique, the terminal sends an
XOFF character to the host when it wants the host to stop transmitting and then sends
an XON character when it is ready for the host to resume transmitting.
<H2><A NAME="Heading13"></A><FONT COLOR="#000077">Peer-to-Peer Relationships</FONT></H2>
<P>DECnet, by its very design and intent, promotes peer-to-peer relationships among
its computing nodes. This peer-oriented relationship is at the core of the DNA that
underlies products like the VAXcluster and even DECnet; to obtain true distributed
processing, a network of peer processes (and therefore processors) must be established.</P>
<P>You can see how peer-to-peer relationships contribute to peer-to-peer processing
and communications by looking at remote file handling and task-to-task communications.
Regarding network file access, the entity requesting the remote file could be an
application program, the Network File Transfer (NFT) utility, or just a standard
copy command. In the case of an application program requesting a remote file, Digital
supplies a set of routines called the <I>Network File Access Routines (NFARs)</I>
to assist the program by performing some of the lower levels of the exchange. In
the case of user commands, the interface is handled via <I>Record Management Services
(RMS).</I></P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig06.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig06.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig06.gif"><B>FIG. 2.6</B></A> <I>LAT and CTERM</I></P>
<P>On the other side of the equation (that is, the computing node with the file to
be accessed), resides a utility called the <I>File Access Listener (FAL).</I> FAL
listens for network requests for files on its node and translates the network request
into a local operation. FAL communicates with the requesting entity via the <I>Data
Access Protocol (DAP),</I> which is part of the DNA. In truth, DAP actually handles
most of the file transfer, another sign of how deep the peer-to-peer relationship
is embedded in DECnet.</P>
<P>The issue of task-to-task communications is, however, a bit more complex. A task
might have to communicate with another task that might not be running; or maybe it
is running, but is unable to respond. Therefore, programs performing this type of
network communications must follow some basic rules.</P>
<P>These rules, or <I>task-to-task communications,</I> begin with one program requesting
a logical link to another program and identifying the location (node) and name of
the target program. If the program is not known on the remote node or if the program
is not able to receive communications, the network will reject the link request.
If, on the other hand, the program is available and ready, then the link request
will be delivered to the program, and then the program will accept or reject the
request.</P>
<P>After the link has been requested and accepted, the programs can exchange data.
Information can be sent one or both ways--it is a function of the application, not
the network. When the communications are complete, one of the programs requests a
termination of the link, and that logical link is disassembled.</P>
<P>In 1990, Digital refined the marketing of its peer-to-peer relationships with
the introduction of Network Application Support (NAS). Targeted to compete against
IBM's Systems Application Architecture (SAA), NAS is offered as a set of software
products for developing and implementing distributed processing systems or client/server
applications. Behind the marketing hype is Digital's solid peer-to-peer technology.
<H2><A NAME="Heading14"></A><FONT COLOR="#000077">PC Integration Strategy</FONT></H2>
<P>Although Digital Equipment's PC product line has some shaky history, there is
nothing shaky about its PC integration strategy. Because Digital has such a strong
LAN foundation with its DECnet strategy, the integration of PCs is simply a matter
of interfacing them with the existing network. Furthermore, because of the wide presence
of Digital midrange computers in the general marketplace, PC LAN vendors such as
Novell have developed special products that enable Digital machines to participate
in their third-party network architectures.</P>
<P>Digital Equipment provides two approaches to integration (see Figure 2.7).</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig07.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig07.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig07.gif"><B>FIG. 2.7</B></A> <I>PC-DECnet Integration with DECnet-DOS
and PCSA</I></P>
<P>To integrate PCs into the standard DECnet architecture, Digital provides <I>DECnet-DOS,</I>
which enables a PC to function as a DECnet computing node. DECnet-DOS offers the
following fundamental capabilities:

<UL>
	<LI><I>Task-to-task communication.</I> PC-based programs can use standard DECnet
	task-to-task communications.<BR>
	<BR>
	
	<LI><I>Remote file access.</I> The PC can initiate file exchanges with other DECnet
	computing nodes using the NFT utility.<BR>
	<BR>
	
	<LI><I>VT220 terminal emulation.</I> The PC can act as a terminal to access DECnet
	applications using the SETHOST utility. This utility makes the PC appear as if it
	were a terminal, physically attached to the target system. SETHOST also provides
	full local printer support with Digital printers.<BR>
	<BR>
	
	<LI><I>Use of disk space.</I> The PC can use disk space on a remote DECnet node as
	if it were local.
</UL>

<P>A DECnet-DOS node can be connected to the network with an Ethernet or asynchronous
DECnet connection, using the PC's COM port as a physical link. The system to which
the PC is attached must be a DECnet Phase IV, full-function node, supporting asynchronous
DDCMP. For read-only operations, multiple DECnet-DOS nodes can simultaneously access
the same network disk.</P>
<P>The other approach is Digital's Pathworks, formerly Personal Computing Systems
Architecture (PCSA), which is a set of services that includes DECnet-DOS. Its benefits
(in addition to those already listed for DECnet-DOS) are as follows:

<UL>
	<LI>Support for a variety of PC client workstations, including DOS, Windows, OS/2,
	Macintosh, Windows NT, NetWare, LAN Manager, and Windows for Workgroups.<BR>
	<BR>
	
	<LI>Data sharing with UNIX and OpenVMS workstations, and VT or 3270 terminals.<BR>
	<BR>
	
	<LI>Support for a variety of servers, including UNIX, Windows NT, OpenVMS, and OS/2.<BR>
	<BR>
	
	<LI>Support for most network protocols, including TCP/IP, DECnet, IPX/SPX, NetBEUI,
	AppleTalk, and LAT. Access to gateways is also provided for SNA and X.25 networks.<BR>
	<BR>
	
	<LI>The option to boot from the network so that PCs without hard disk drives can
	be configured to load their operating system and programs from a VAX-based virtual
	disk.<BR>
	<BR>
	
	<LI>Print server capabilities whereby the networked PCs can use the print resources
	of the VAX server (in other words,