DECnet-Plus

DECnet is the collective name for the family of communications products (software and hardware) that allow Digital operating systems to participate in a network.

VSI DECnet for OpenVMS on Alpha and Integrity servers allows a suitably configured OpenVMS system to participate as an end node. With proper network planning, DECnet networks can contain up to 1,023 nodes per network area and up to 63 areas per network. 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.

DECnet for OpenVMS is a layered product that ships with the Alpha and Integrity server operating systems. On OpenVMS Alpha systems, 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. On OpenVMS Integrity server systems, the DECnet for OpenVMS license is part of the Base Operating Environment (BOE), which is licensed on a per-core license basis. DECnet for OpenVMS is warranted only for use with Phase IV and DECnet-Plus (formerly DECnet/OSI) products supported by VSI.

DECnet for OpenVMS offers task-to-task communications, file management, down-line system and task loading, network command terminals, and network resource sharing capabilities using the Digital Network Architecture (DNA) protocols. DECnet for OpenVMS communicates with adjacent and nonadjacent Phase IV and DECnet-Plus 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 SPD. The functions available to users on mixed networks can be determined by a comparison of the SPDs for the appropriate DECnet products.

Features

DECnet for OpenVMS offers the following features:

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, Record Management System (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 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-Plus nodes, or on any two nonadjacent Phase IV or DECnet-Plus nodes in the same network connected by Phase IV or DECnet-Plus 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 systems 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: ANALYZE, APPEND, BACKUP, CLOSE, CONVERT, COPY, CREATE, DELETE, DIFFERENCES, DIRECTORY, DUMP, OPEN, PRINT, PURGE, READ, SEARCH, SUBMIT, TYPE, and WRITE. 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®, UNIX, 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 format- ted 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 supported for VSI 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 check-pointed 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 VSI 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.
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 VMScluster 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 VMScluster Software Product Description for relevant restrictions. DECnet and DECnet-Plus nodes can coexist in the same cluster. However, DECnet and DECnet-Plus must have separate system disks, and they cannot share the same cluster alias. The DECnet for OpenVMS Alpha cluster alias requires that at least one node in the VMScluster be licensed as an Extended Function node.
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. 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.
LAN Failover. DECnet for OpenVMS provides support for OpenVMS LAN failover sets. LAN failover provides a mechanism to protect LAN applications against network interface card (NIC) failures. A LAN failover set is defined by the system manager and consists of a set of like adapters (all the same class) that support LAN failover. One adapter in the failover set is used for LAN traffic; one or more other adapters in the set remain idle. If the active adapter fails, one of the idle adapters in the set automatically takes over LAN traffic using the same address as the failed adapter.
DECnet for OpenVMS Operation. DECnet for OpenVMS 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 VSI. 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.