DIGITAL Software Product Description _________________________________________________________________________ PRODUCT NAME: DECnet for OpenVMS VAX and Alpha, Version 7.0 SPD 48.48.04 Note: This Software Product Description covers DECnet for OpenVMS on VAX and Alpha platforms. Unless explicitly noted, the features described apply to both platforms. Licenses and Part Numbers are platform specific and are noted in the Ordering Information section of this SPD. DESCRIPTION DECnet for OpenVMS on VAX and Alpha allows a suitably configured OpenVMS system to participate as an end node or, on VAX systems only, a routing 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 end node and full (VAX) or Extended (Alpha) function products are licensed separately for OpenVMS systems. The DECnet for OpenVMS License Product Authorization Key (PAK), when registered on an OpenVMS system, enables communication between systems using the DECnet protocols. DECnet for OpenVMS has been implemented in accordance with Phase IV of the Digital Network Architecture (DNA). product. It ships with the OpenVMS operating system and is separately licensed. DECnet for OpenVMS is warranted only for use with Phase IV and DECnet/OSI products supported by Digital Equipment Corporation. DECnet for OpenVMS offers task-to-task communications, file management, downline system and task loading, network command terminals, and December 1995 network resource sharing capabilities using the Digital Network Architecture (DNA) protocols. DECnet for OpenVMS communicates with adjacent and nonadjacent Phase IV and DECnet/OSI nodes. OpenVMS programs written in MACRO and native mode high-level languages can use DECnet for OpenVMS VAX capabilities. The network functions available to a DECnet for OpenVMS user depend, in part, on the configuration of the rest of the network. Each DECnet product offers 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 Phase IV nodes have all the functions described in this Software Product Description (SPD). The functions available to users on mixed networks can be determined by a comparison of the SPDs for the appropriate DECnet products. Routing capabilities are offered on OpenVMS VAX systems only. A Full Function DECnet for OpenVMS VAX License PAK must be registered on a node in order for that node to operate as a routing node. For a node to operate as an end node, either the Full Function or the End Node DECnet for OpenVMS VAX License PAK must be registered on that node. Full Function DECnet for OpenVMS VAX software allows a node to be set up as either a routing node or as an end node. See Appendix A of this Software Product Description for more information on routing capabil- ities in DECnet for OpenVMS VAX systems. Standard DECnet for OpenVMS 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 duplex, 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 2 offered by means of the System Service interface that extends the capabilities provided by the transparent mode. These capabilities include support for interrupt messages and multiple inbound connect requests. Using DECnet for OpenVMS an OpenVMS program can exchange messages with other user programs. The two user programs can be on the same node, on adjacent Phase IV or DECnet/OSI nodes, or on any two nonadjacent Phase IV or DECnet/OSI nodes in the same network connected by Phase IV or DECnet/OSI routing nodes. DECnet for OpenVMS imposes no special data formatting requirements on the user. Network Resource Access File Access - File access is supported to and from remote DECnet sustems 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 to a file, several other access methods are supported through RMS using DECnet for OpenVMS. These methods include random access by relative record number, random access by key value, random access by Record File Address (RFA), and block I/O access by virtual block number. Proxy Access 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, APPEND, BACKUP, CLOSE, CONVERT, COPY, CREATE, DELETE, DIFFERENCES, DIRECTORY, 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 3 /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 compatible file structures and record formats. Sequential or relative files with fixed length, variable length, or variable length with fixed control field records can be transferred between two OpenVMS systems. Similarly, 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 for OpenVMS also allows OpenVMS command files to be received from other systems and executed. The DCL command EXCHANGE/NETWORK, allowing for the transfer of files to or from heterogeneous systems, is available. This command gives users the option to transfer file types between MS-DOS[R] or ULTRIX systems and OpenVMS systems 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 for OpenVMS allows for the loading of an unattended system using the services provided by the Maintenance Operations Module (MOM). MOM provides a set of maintenance operations over various types of circuits by using the Maintenance Operations Protocol (MOP). A loadable system is a system that has a load device enabled for MOP service functions and for which a properly formatted load file is supplied. Downline 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, DECnet for OpenVMS permits the user to load routing software from the OpenVMS node downline to the target node. Load requests can come from the local DECnet for OpenVMS operator or from the target node. Downline loading is 4 supported for Digital server products. However, this facility is not supported over asynchronous lines. Downline Task Loading Initial task images for loadable systems can be stored on OpenVMS file system devices and loaded into remote nodes. Programs already executing on loadable remote systems can be checkpointed to the host OpenVMS file system and later restored to main memory in the remote node. These features simplify the operation of network systems that do not have mass storage devices. This facility is not supported over asynchronous lines. Upline Dumping Memory images of adjacent nodes connected by DECnet can be written or dumped into a file on an OpenVMS system. This facility helps the system manager in fault isolation on a remote system. This facility is also supported for Digital server products. This facility is not supported over asynchronous lines. Network Command Terminal The DCL command SET HOST allows a terminal user on one DECnet node to establish a logical connection to another DECnet node that uses the Command Terminal Protocol (CTERM). This connection makes the terminal appear physically connected to the remote system and the operator can use all the standard system and network utilities supported by that remote node. This capability is particularly useful for doing remote program development and allows the terminal users on smaller application-oriented systems to use the resources of larger development- oriented systems. OpenVMS MAIL Utility The OpenVMS MAIL utility allows transmission of text messages between users of a standalone system. The DECnet for OpenVMS software allows users to send and receive OpenVMS MAIL to or from users of other systems that operate within the same DECnet network. 5 OpenVMS PHONE Utility The OpenVMS PHONE utility allows users to send and receive data interactively from one user's terminal to another user's terminal. DECnet increases the scope of OpenVMS PHONE to allow active users on different systems in the same network to exchange information. Cluster Alias DECnet supports the ability to access some or all nodes in a VMSclusater using a separate alias node address, while retaining the ability to address each node in the cluster individually. Not all network objects may be accessed using this mechanism. More than 64 nodes can operate within a cluster, but the maximum number of nodes that are allowed to participate in the cluster alias is 64. Refer to the VAX VMScluster Software Product Description (SPD 29.78.xx) or to the Alpha VMScluster Software Product Description (SPD 42.18.xx) for relevant restrictions. DECnet and DECnet/OSI nodes can coexist in the same cluster. However, DECnet and DECnet/OSI must have separate system disks, and they cannot share the same cluster alias. The DECnet for OpenVMS VAX cluster alias requires that at least one node in the VMScluster be a VAX system licensed as a Full Function node. The DECnet for OpenVMS Alpha cluster alias requires that at least one node in the VMScluster be licensed as an Extended Function node. Refer to the DECnet/OSI documentation for details on configuring a DECnet/OSI cluster alias. Network Management The Network Control Program (NCP) performs three primary functions: displaying statistical and error information, controlling network components, and testing network operation. These functions can be performed locally or executed at remote Phase IV nodes that support these functions. NCP allows for planning, building, tuning, and controlling DECnet networks. NCP can be used to create and manage networks including local node operation, remote node operation, circuits, lines, and objects. 6 An operator can display the status of DECnet activity at any Phase IV node in the network. The user can choose to display statistics related to the node itself or the communication lines attached to that node, including traffic and error data. The local operator can also perform many network control functions such as starting and stopping 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 the event logging facility. NCP can also be used to test components of the network. NCP enables transmission and reception of test messages over individual lines either between nodes or through other controller loopback arrangements. 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 operating system 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 developed on an individual system can be used in a network environment without being modified. Communications Options DECnet for OpenVMS uses Ethernet and FDDI communications controllers to interface with other network nodes. DECnet for OpenVMS Operation DECnet for OpenVMS VAX is implemented under the OpenVMS operating system as an Ancillary Control Process (ACP) and a network device driver with executive-level components and user-level programs supplied by Digital. 7 The normal OpenVMS protection has been incorporated in the operation of DECnet for OpenVMS 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 for OpenVMS Configuration and Performance 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 DECnet for OpenVMS node is a function not only of the expected network traffic and resultant processing, but also of the amount of concurrent processing specific to that node. Thus, node performance depends on many factors 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 o Size and frequency of route-through traffic (on DECnet for OpenVMS VAX routing nodes only) 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 8 quality, protocol overhead, topology, and network application(s), as well as the factors cited in this section. INSTALLATION For the first installation of this product, Digital recommends the purchase of 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 requirements (as specified in the relevant SPDs). o Prior to installing Digital hardware or software, obtain, install, and demonstrate as operational any modems and other necessary customer equipment or facilities to which Digital's communication hardware or software will connect. 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 facilities 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 for OpenVMS will consist of the following: o Verification that all components of DECnet for OpenVMS 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 Digital Software Specialist be required to modify the previously installed operating system parameters, a time and materials charge will apply. 9 o Create any necessary DECnet accounts and directories. o Enable software via License Product Authorization Key (PAK) registration. o Define and create a local node DECnet database. o Modify the system's startup command procedure to include startup of the DECnet for OpenVMS network. o Verify the proper installation of DECnet for OpenVMS by running a series of tests to show connectivity to a designated node. Connectivity to all other nodes within the network is the responsi- bility of the customer. HARDWARE REQUIREMENTS Refer to the OpenVMS Operating System Software Product Description (SPD 25.01.xx) for hardware requirements and processor support. Reference can be made to the configuration charts listed in the OpenVMS Operating System SPD. For general device or controller descriptions, please refer to the Networks and Communications Buyers Guide. CLUSTER ENVIRONMENT DECnet for OpenVMS is fully supported when installed on any valid and licensed VMScluster configuration without restrictions. The HARDWARE REQUIREMENTS section of the OpenVMS Operating System Software Product Description (SPD 25.01.xx) details any special hardware required or not supported by this product. VMScluster software provides a distributed computing environment across a highly integrated set of VAX, Alpha, and/or MicroVAX systems that operate as a single environment. VMScluster members can share many resources such as disk and tape storage, CPU resources, and system management operations. Within this highly integrated environment, systems retain their independence because they use local, memory-resident copies of the OpenVMS operating system. Thus, members can boot and fail independently while benefiting from common resources. 10 VMScluster configurations are fully described in the VMScluster Software Product Description (29.78.xx) and include CI, Ethernet, and Mixed Interconnect configurations. SOFTWARE REQUIREMENTS DECnet for OpenVMS requires the following: o OpenVMS Operating System Version 6.2 or OpenVMS Operating System Version 7.0 Only the Base OpenVMS Kit component is required. OPTIONAL SOFTWARE DEC X.25 Client for OpenVMS Alpha Systems allows a suitably config- ured DECnet for OpenVMS Alpha system to make logical connections to Packet Switched Data Networks (PSDN) via one or more X.25 connector nodes on the same Local Area Network. Refer to the DEC X.25 Client for OpenVMS Alpha System Software Product Description (SPD 46.37.xx) for further details. The TCP/IP Services for OpenVMS software can be installed to provide a TCP/IP environment on an OpenVMS system. TCP/IP Services for OpenVMS systems include capabilities such as file transfer (FTP), TELNET, Virtual Terminal support, and more. Refer to the TCP/IP Services for OpenVMS VAX Software Product Description (SPD 25.A4.xx) or the TCP/IP Services for OpenVMS Alpha Software Product Description (SPD 46.46.xx) for more information. GROWTH CONSIDERATIONS The minimum hardware/software requirements for any future version of this product may be different from the requirements for the current version. 11 DISTRIBUTION MEDIA DECnet for OpenVMS VAX is distributed on the following media: o TK50 streaming tape o 9-track 1600 BPI Magtape o CD-ROM DECnet for OpenVMS Alpha is distributed on CD-ROM. ORDERING INFORMATION DECnet for OpenVMS software is shipped on the OpenVMS Kit. DECnet for OpenVMS licenses also include the right to use DECnet/OSI for OpenVMS. Base License Option Numbers for DECnet for OpenVMS VAX are as follows: End Node QL-D04A*-AA Full Function QL-D05A*-AA End Node to Full QL-D09A*-AA Function Upgrade Base License Option Numbers for DECnet for OpenVMS Alpha are: End System QL-MTFA*-AA Extended Function QL-MTGA*-AA End System to Ex- QL-MTHA*-AA tended Function Upgrade * Denotes processor variant. 12 SOFTWARE LICENSING The DECnet for OpenVMS License provides the right to use the software product on a single CPU and includes the delivery of a License Product Authorization Key (PAK) to enable DECnet for OpenVMS software. To use this software product on additional CPUs, users must purchase a Single-Use License Option for each CPU. The DECnet for OpenVMS VAX End Node and the DECnet for OpenVMS End System License grants the right to use all the DECnet features with the exception of cluster alias support. The DECnet for OpenVMS VAX Full Function and the DECnet for OpenVMS Alpha Extended Function license is required for cluster alias support. This software is furnished under the licensing provisions of Digital Equipment Corporation's Standard Terms and Conditions. For more information about Digital's licensing terms and policies, contact your local Digital office. LICENSE MANAGEMENT FACILITY SUPPORT This product supports the OpenVMS 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 Operating System Software Product Description (SPD 25.01.xx) or the License Management Facility manual of the OpenVMS operating system documentation set. SOFTWARE PRODUCT SERVICES A variety of service options are available. For more information, contact your local Digital office. 13 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 Addendum 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. Appendix A: DECnet for OpenVMS VAX Routing Routing Capabilities on OpenVMS VAX A DECnet for OpenVMS VAX node must function as a routing node whenever multiple circuits are used by that node. Routing nodes maintain information on the paths to other nodes in the network. DECnet for OpenVMS VAX end nodes provide all the capabilities of DECnet for OpenVMS VAX routing nodes with the exception that end nodes cannot route messages on behalf of other nodes in the network. Since end nodes do not route messages, they do not need to maintain routing information. Consequently, end nodes initiate less overhead message traffic than routing nodes and, therefore, consume less processing power than routing nodes. Adaptive Routing is the mechanism that routing nodes use to ``adapt'' or choose other physical paths if the physical paths the routing nodes are using fail or change line cost. In addition to adaptive routing, DECnet for OpenVMS VAX supports area routing. Area routing is a method by which DECnet can send and route messages between the nodes in different areas of the network. Up to 63 areas with up to 1,023 nodes per area are allowed. The network manager has the option of separating a network into areas. Area-based DECnet networks are hierarchical networks and some restrictions apply to communications from nodes in one area to nodes in another area. However, it is not required that all nodes in the network be DECnet for OpenVMS VAX or even Phase IV nodes. Proper network planning is essential when using area routing or configuring large networks. Valid topologies are the responsibility of the customer. 14 Note: Only 32 routers (dedicated and/or host based) are supported on an extended LAN. A DECnet for OpenVMS VAX node has the ability to communicate with a remote node over multiple circuits simultaneously, as long as those circuits are all of equal cost and provide the lowest cost path. DECnet for OpenVMS VAX routing nodes will split transmission of a packet load to a destination node via multiple paths if those paths are of equal lowest cost. This capability is called Equal Cost Path Splitting. This feature can increase throughput of data by using all the best available paths. In order to take full advantage of this capability, all intermediate routing nodes should also support this feature and all destination nodes must support out-of-order packet caching. ©1995 Digital Equipment Corporation. All rights reserved. [R] MS-DOS is a registered trademark of Microsoft Corporation. [TM] CI, DECnet, Digital, DNA, Ethernet, MicroVAX, OpenVMS, VAX, VMScluster, VAX MACRO, and ULTRIX and the Digital logo are trademarks of Digital Equipment Corporation. 15