Software Product Description ___________________________________________________________________ PRODUCT NAME: DECnet Version 1.5 for OpenVMS AXP SPD 42.25.01 DESCRIPTION DECnet for OpenVMS AXP allows a suitably configured OpenVMS AXP sys- tem to participate as an end node in DECnet computer networks. With proper network planning, DECnet networks can contain up to 1,023 nodes per network area and up to 63 areas per network. DECnet for OpenVMS AXP is a Phase IV network product and is warranted only for use with Phase III, Phase IV, and Phase V products supported by Digital Equipment Corporation. DECnet offers task-to-task communications, file management, downline system and task loading, network command terminals, and network re- source sharing capabilities using the Digital Network Architecture (DNA) protocols. DECnet communicates with adjacent and non-adjacent Phase III, Phase IV, and Phase V nodes (adjacent nodes are connected by a single communications line). The network functions available to a DECnet user depend, in part, on the configuration of the rest of the network. Each DECnet product of- fers its own subset of Digital Network Architecture (DNA) functions and its own set of features to the user. Networks consisting entirely of DECnet for OpenVMS AXP Phase IV nodes have all the functions de- scribed in this Software Product Description. The functions available to users on mixed networks can be determined by a comparison of the SPDs for the appropriate DECnet products. There are two DECnet for OpenVMS licenses: End System (also called End Node) and Extended Function. The End System license enables all the DECnet features for a single node and allows communications with other DIGITAL May 1993 nodes over one circuit. The Extended Function license includes the fea- tures of the End System license and enables a DECnet for OpenVMS AXP node in a VMScluster to act as a cluster alias router. No other rout- ing functions are supported by DECnet for OpenVMS AXP systems. Standard DECnet Capabilities Task-to-Task Communication For most applications, task-to-task communication can be programmed in a transparent manner where the remote task is treated as a full du- plex, record-oriented device. Transparent operation is provided via the following interfaces: System Service calls, RMS calls (OPEN, GET, PUT, and CLOSE), and high-level language I/O statements (which are mapped to RMS calls). A nontransparent mode of task-to-task communication is offered by means of the System Service interface that extends the ca- pabilities provided by the transparent mode. These capabilities in- clude support for interrupt messages and multiple inbound connect re- quests. Using DECnet, an OpenVMS AXP program can exchange messages with other user programs. The two user programs can be on the same node, on ad- jacent Phase III, Phase IV, or Phase V nodes, or on any two nonadja- cent Phase III, Phase IV, or Phase V nodes in the same network con- nected by Phase III, Phase IV, or Phase V routing nodes. DECnet im- poses no special data formatting requirements on the user. Network Resource Access File Access - File access is supported to and from remote DECnet sys- tems transparent to programs using RMS. User programs can sequentially read, create, and delete files on a remote node. Record Access - User programs can perform record level operations such as GET, PUT, UPDATE, DELETE, FIND, and REWIND to access and modify files residing on a remote OpenVMS node. In addition to sequential access 2 to a file, several other access methods are supported through RMS us- ing DECnet. These methods include random access by relative record num- ber, random access by key value, random access by Record File Address (RFA), and block I/O access by virtual block number. Proxy Access Proxy Access allows local access to remote resources without trans- mitting access control information over the network. Remote users can have access to up to 15 proxy accounts on a specific remote system. One proxy account should be designated as the default proxy account on the remote system. Command Language File Management Most OpenVMS Digital Command Language (DCL) commands can be used to perform network file operations. These commands include: ANALYZE, AP- PEND, BACKUP, CLOSE, CONVERT, COPY, CREATE, DELETE, DIFFERENCES, DI- RECTORY, DUMP, OPEN, PRINT, PURGE, READ, SEARCH, SUBMIT, TYPE, and WRITE. The operation of these commands is transparent except for commands that invoke processing on a specific system (i.e., SUBMIT/REMOTE and PRINT /REMOTE). Only a node name added to a file specification is required to invoke the network capabilities via one of these commands. Using the COPY command, a user can transfer sequential, relative, and indexed-sequential (ISAM) files between DECnet nodes that support com- patible file structures and record formats. Sequential or relative files with fixed length, variable length, or variable length with fixed con- trol field records can be transferred between two OpenVMS systems. Sim- ilarly, multikeyed indexed files with variable or fixed length records are supported. The SUBMIT/REMOTE command allows command files residing on a remote node to be submitted for execution at the remote node. The command file must be in the format expected by the node responsible for execution. DECnet allows OpenVMS command files to be received from other systems and executed. 3 The DCL command EXCHANGE/NETWORK allows for the transfer of files to or from heterogeneous systems. This command gives users the option to transfer file types between MS-DOS(R) or ULTRIX systems and OpenVMS sys- tems regardless of record semantics. Unlike the COPY command, which preserves file and record organization during a file transfer, this command enables the user to modify file and record attributes during file transfer. Downline System Loading DECnet allows for the loading of an unattended system using the ser- vices provided by the Maintenance Operations Module (MOM). MOM pro- vides a set of maintenance operations over various types of circuits by using the Maintenance Operations Protocol (MOP). A loadable sys- tem is a system that has a load device enabled for MOP service func- tions and for which a properly formatted load file is supplied. Down- line loading involves transferring a copy of the properly formatted load file image of a remote node's operating system from an OpenVMS node to the unattended target node. For example, a router may be loaded from a DECnet for OpenVMS node. Load requests can come from the lo- cal DECnet operator or from the target node. Downline loading is sup- ported for Digital server products. However, this facility is not sup- ported over asynchronous DECnet connections. Downline Task Loading Initial task images for loadable systems can be stored on OpenVMS file system devices and loaded into remote nodes. Programs already execut- ing on loadable systems can be checkpointed to the host OpenVMS file system and later restored to the remote system. These features sim- plify the operation of network systems that do not have mass storage devices. Upline Dumping Memory images of adjacent loadable systems connected by DECnet can be written or dumped into a file on an OpenVMS system. This facility helps a programmer understand what caused the system to crash. Network Command Terminal 4 The DCL command, SET HOST, allows a terminal user on one DECnet node to establish a logical connection to another DECnet node or other types of DECnet nodes that use the Command Terminal Protocol (CTERM). This connection makes the terminal appear physically connected to the re- mote system and the operator can use all the standard system and net- work utilities supported by that remote node. This capability is par- ticularly useful for doing remote program development and allows the terminal users on smaller systems to use the resources of larger sys- tems. OpenVMS MAIL Utility OpenVMS MAIL allows transmission of text messages between users of a standalone OpenVMS system. The DECnet for OpenVMS AXP software allows users to send and receive OpenVMS MAIL to or from users of other sys- tems that operate within the same DECnet network. OpenVMS PHONE Utility The OpenVMS PHONE utility allows users to send and receive data in- teractively from one user's terminal to another user's terminal. DEC- net increases the scope of OpenVMS PHONE to allow active users on dif- ferent systems in the same DECnet network to exchange information. Network Management The Network Control Program (NCP) performs three primary functions: displaying statistical and error information, controlling network com- ponents, and testing network operation. These functions can be per- formed locally or executed at remote Phase III or Phase IV nodes that support these functions. The NCP facility allows for planning, build- ing, tuning, and controlling DECnet networks. NCP can be used to cre- ate and manage networks including local node operation, remote node operation, circuits, lines, and objects. An operator can display the status of DECnet activity at any Phase III or Phase IV node in the network. The user can choose to display statis- tics related to the node itself or the communication lines attached to that node, including traffic and error data. The local operator can 5 also perform many network control functions such as starting and stop- ping lines, activating the local node, and downline loading systems. DECnet provides network event logging to a terminal device or disk file. Any logged event can be used to monitor, diagnose, and tune a network. The NCP utility can be used to enable and disable event logging. NCP can also be used to test components of the network. NCP enables transmission and reception of test messages over individual lines be- tween nodes. The messages can then be compared for possible errors. NCP allows the performance of a logical series of tests that will aid in isolating network problems. Integrated Interfaces DECnet interfaces are standard parts of the OpenVMS AXP operating sys- tem for use on local, standalone systems. Users can develop programs and procedures based upon these interfaces for such functions as file access and task-to-task communication on individual systems. Since the DECnet interfaces stay the same, the programs and procedures devel- oped on an individual system can be used in a network environment with- out being modified. Communications Options DECnet uses Ethernet or FDDI communications controllers to interface with other network nodes. DECnet Operation The normal OpenVMS protection has been incorporated in the operation of DECnet. For example, incoming connects including file access and file transfer requests are protected by the normal OpenVMS login and file protection mechanisms. Outgoing connects, including file access and file transfer requests, can include user password information that is implicitly specified via NCP or explicitly specified by the user for verification on the remote node. DECnet Configuration and Performance 6 The process of configuring a DECnet node is based primarily on trade- offs of cost, performance, and functionality while satisfying the user's application requirements. It can be expected that network applications will range from low-speed, low-cost situations to those of relatively high performance and functionality. The performance of a given DEC- net node is a function not only of the expected network traffic and resultant processing, but also of the amount of concurrent process- ing specific to that node. Thus, node performance depends on many fac- tors including: o CPU type o Number and type of devices attached to the particular CPU o Number of device interrupts per unit time o Communication line(s) characteristics o Number and size of buffers o Message size and frequency of transmission o Applications in use It is important to note that the rate at which user data can be trans- mitted (throughput) over a communications line can sometimes approach, but will never exceed, the actual line speed. The reason is that the actual throughput is a function of many factors, including the line quality, protocol overhead, topology, and network application(s), as well as the factors cited in this section. DECnet Cluster Alias DECnet for OpenVMS AXP supports the ability to access some or all DEC- net nodes in a VMScluster using a separate alias node address, while retaining the ability to address each node in the cluster individu- ally. Not all network objects may be accessed using this mechanism. More than 64 nodes may operate within a VMScluster, but the maximum number of nodes allowed to participate in the DECnet cluster alias is 64. Refer to the Software Product Description for VMScluster Software (SPD 42.18.xx) for relevant restrictions on VMScluster configurations. 7 At least one node in the VMScluster must be configured as a cluster alias router in order to use this feature. INSTALLATION Only experienced customers should attempt installation of this prod- uct. Digital recommends that all other customers purchase Digital's Installation Services. These services provide for installation of the software product by an experienced Digital Software Specialist. Customer Responsibilities Before Digital can install the software, the customer must: o Ensure that the system meets the minimum hardware and software re- quirements. o Prior to installing Digital hardware or software, obtain, install, and demonstrate as operational any customer equipment or facili- ties to which Digital's communication hardware or software will con- nect. o Designate one adjacent node to verify installation/connectivity. o Make available for a reasonable period of time, as mutually agreed upon by Digital and the customer, all hardware communication fa- cilities and terminals that are to be used during installation. Delays caused by any failure to meet these responsibilities will be charged at the then prevailing rate for time and materials. Installation for DECnet will consist of the following: o Verification that all components of DECnet have been received. o Verification that the necessary versions of the OpenVMS software and documentation are available. o Verification of the appropriate SYSGEN parameters. Note: Should a software specialist be required to modify the pre- viously installed operating system parameters, a time and materi- als charge will apply. 8 o Create any necessary DECnet accounts and directories. o Enable software via License Product Authorization Key (PAK) reg- istration. o Define and create a local node DECnet database. o Modify the system's startup command procedure to include startup of the DECnet network. o Verify the proper installation of DECnet by running a series of tests to show connectivity to a designated node. Connectivity to all other nodes within the network is the respon- sibility of the customer. Digital recommends the use of the NCP fa- cility to help verify connectivity. HARDWARE REQUIREMENTS DECnet for OpenVMS AXP supports the Ethernet and FDDI controllers listed in the OpenVMS AXP Operating System Software Product Description (SPD 41.87.xx). One such device is required on a DECnet system. Refer to the OpenVMS AXP Operating System Software Product Descrip- tion (SPD 41.87.xx) for processor support. Reference can be made to the configuration charts listed in the OpenVMS AXP Operating System SPD. For general device or controller descriptions, please refer to the Networks and Communications Buyers Guide. Note that DECnet for Open- VMS AXP does not support any synchronous or asynchronous DDCMP devices. SOFTWARE REQUIREMENTS o OpenVMS AXP Operating System V1.5 9 GROWTH CONSIDERATIONS The minimum hardware/software requirements for any future version of this product may be different from the requirements for the current version. DISTRIBUTION MEDIA CD-ROM ORDERING INFORMATION Software Licenses: End System: QL-MTFA*-AA Extended Function: QL-MTGA*-AA * Denotes variant fields. For additional information on available li- censes, refer to the appropriate price book. DECnet for OpenVMS AXP software and documentation are shipped as part of the OpenVMS AXP operating system software and documentation kits for all processors. SOFTWARE LICENSING The DECnet licenses give users the right to use the software on a sin- gle CPU and includes the delivery of a License Product Authorization Key (PAK) to enable the DECnet for OpenVMS AXP software. To use this software product on additional CPUs, users must purchase a Single-Use License Option for each CPU. The End System license grants the right to use all the DECnet features with the exception of routing (an Extended Function license is required for cluster alias routing). 10 An Extended Function license grants the right to use the DECnet End System features and enables a DECnet node participating in a VMSclus- ter to act as a cluster alias router. No other routing functions are supported with this license. An Extended Function license is required on at least one DECnet for OpenVMS AXP node in a VMScluster of AXP sys- tems if the cluster alias feature is to be used. Alternatively, a VAX node in a dual-architecture cluster could act as the cluster alias router. This software is furnished under the licensing provisions of Digital Equipment Corporation's Standard Terms and Conditions. For more in- formation about Digital's licensing terms and policies, contact your local Digital office. License Management Facility Support: This product supports the Digital License Management Facility. License units for this product are allocated on a CPU Capacity basis. For more information on the License Management Facility, refer to the OpenVMS AXP Operating System Software Product Description (SPD 41.87.xx) or documentation set. SOFTWARE PRODUCT SERVICES A variety of service options are available. For more information, con- tact your local Digital office. SOFTWARE WARRANTY Warranty for this software is provided by Digital with the purchase of a license for the product as defined in the Software Warranty Ad- dendum of this SPD. The above information is valid at time of release. Please contact your local Digital office for the most up-to-date information. 11 (R) MS-DOS is a registered trademark of Microsoft Corporation. [TM]The Digital Logo, AXP, DDCMP, DECnet, Digital, DNA, OpenVMS, ULTRIX, and VMScluster are trademarks of Digital Equipment Corporation. 12