HP OpenVMS Systems Documentation
DECnet-Plus for OpenVMS
DECnet-Plus for OpenVMS implements standards approved by:
Table 1-2 lists the OSI standards that DECnet-Plus for OpenVMS supports. Note that for LANs at the Data Link and Physical layers, ISO standards are equivalent to IEEE standards.
|ISO 7498||Basic Reference Model|
|Application||ISO 8571||File Transfer, Access and Management (FTAM)|
|ISO 8649||Service Definition --- Association Control|
|ISO 8650||Association Control Service Element (ACSE)|
|ISO 9041||Virtual Terminal Protocol|
|ISO 9072||Remote Operations Service Element|
|Presentation||ISO 8822||Presentation Service|
|ISO 8823||Presentation (Kernel)|
|Session||ISO 8326||Connection-Oriented Network Service (CONS)|
|ISO 8327||Connection-Oriented Network Service Protocol|
|ISO 9595||Common Management Information Service Element (CMISE)|
|Transport||ISO 8072||Connection-Oriented Transport Service (COTS) Definition|
|ISO 8073||Connection-Oriented Transport Service (COTS) Protocol|
|RFC 1006||Defines how to implement ISO 8073 Transport Class 0 on top of TCP|
|RFC 1006 Extension (Internet Draft)||Defines how to implement ISO 8073 Transport Class 2 non-use of Explicit Flow Control on top of TCP|
|Network||ISO 7498 Addendum 1||Connectionless-Mode Transmission|
|ISO 8208||X.25 Packet Level Protocol (PLP)|
|ISO 8348||Service definition: Connection-Oriented Network Service (CONS)|
|ISO 8348 Addendum 2||OSI addressing formats|
|ISO 8473, 8348 Addendum 1||Connectionless-Mode Network Service (CLNS)|
|ISO 8878||X.25/Connection-Oriented Network Service (CONS)|
|ISO 8881||X.25 Packet Level Protocol in local area networks|
|ISO 9542||End-system to intermediate-system routing exchange protocol|
|Data Link||ISO 3309, 4335, 7809, 8471, 8885||Point-to-point data links (HDLC)|
|ISO 7776||Point-to-point X.25 data links (only with an X.25 license; LAPB, one possible user)|
|ISO 8802-1 (IEEE 802.1) 1||Ethernet support (CSMA-CD)|
|ISO 8802-2 (IEEE 802.2)||Frame formats for 8802-3 LANs (CSMA-CD logical link control (LLC1))|
X.25 logical link control (LLC2)
(one possible user)
|ISO 8802-3 (CSMA/CD)||LAN support (CSMA-CD)|
|ISO 9314||Fiber Distributed Data Interface (FDDI)|
|Physical||ISO 8802-3 (IEEE 802.3)||CSMA-CD devices|
|ISO 9314||Fiber Distributed Data Interface (FDDI)|
|EIA RS-232-C||HDLC point-to-point devices|
|EIA RS-422||HDLC point-to-point devices|
|EIA RS-423||HDLC point-to-point devices|
|CCITT V.35||HDLC point-to-point devices|
The DECnet-Plus for OpenVMS software has several related dependencies
outlined in the following sections.
1.3.1 DECnet Licenses
To use DECnet-Plus for OpenVMS or DECnet Phase IV software, you need the appropriate software licenses. Table 1-3 lists the two basic licenses and three license keys for OpenVMS VAX and Alpha systems, for DECnet Phase IV and DECnet-Plus, respectively.
|VAX Phase IV||VAX DECnet-Plus||Alpha Phase IV||Alpha DECnet-Plus|
|End System License|
|All DECnet Phase IV functionality except cluster alias and routing||All DECnet Phase IV functionality except cluster alias, OSI API 1, OSI application gateways, DECdns server, and routing||All DECnet Phase IV functionality except cluster alias||All DECnet-Plus functionality except cluster alias, OSI API 1, OSI application gateways, and routing|
|Extended Function License|
|All DECnet Phase IV functionality including cluster alias 2 and routing||All DECnet-Plus functionality including cluster alias 2, OSI API, OSI application gateways, DECdns server, and host-based routing 3||All DECnet Phase IV functionality including cluster alias 2 but excluding routing 4||All DECnet-Plus functionality including cluster alias 2, OSI API, OSI application gateways, and host-based routing 3|
For mapping between node names and node addresses, you need at least one of the following three name services:
A DECnet-Plus network can use one name service exclusively, or it can
have a mixture of systems using one or more of the name services. While
configuring DECnet-Plus, you specify one or more of the three available
name services to use on the node. To determine which name service(s) to
use, check which name services are already being used by other nodes in
your network. For example, if the other nodes in your network are
already using DECdns, you will most likely want to use DECdns and join
the existing namespace. The following sections include additional
criteria and dependencies on the name services.
126.96.36.199 Choosing the Local Namespace
Choose the Local namespace if you have a small network and do not wish
to use a distributed namespace. The Local namespace is similar to the
permanent node database (NETNODE_REMOTE.DAT), used on DECnet Phase IV
systems. With the Local namespace, name-to-address mapping information
has to be administered separately on each node. To use the Local
namespace, no additional software is required.
188.8.131.52 Choosing DECdns
With DECdns, all node names in the network can be administered from one
location. The mapping information is stored on two or more DECdns
servers and kept up-to-date networkwide automatically. DECnet-Plus
requires at least two DECdns servers in the network. DECdns server
software must be installed and configured on these systems (the server
software is optional software included with the DECnet-Plus for OpenVMS
software kit). The DECnet-Plus Planning Guide describes planning considerations and
the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration and DECnet-Plus DECdns Management guides include installation and
184.108.40.206 Choosing DNS/BIND
DNS/BIND, the distributed name service for TCP/IP, supports the storage
of IP addresses and the use of node synonyms. Node synonyms allow for
backward compatibility with older applications that cannot use long
domain names. (Note that DECnet-Plus also allows for node synonyms to
provide backward compatibility with DECnet Phase IV node names.)
DNS/BIND is needed if you want DECnet-Plus to run applications over
TCP/IP. To use the DNS/BIND name service, DECnet-Plus requires one or
more DNS/BIND servers in the network. DNS/BIND must be selected as one
of the name services if you plan to use the DECnet over TCP/IP or OSI
over TCP/IP features. See the appropriate TCP/IP documentation for more
information on DNS/BIND.
1.3.3 DECdts Time Server
The DIGITAL Distributed Time Service (DECdts) synchronizes the system
clocks in computers connected by a network. The DECnet-Plus for OpenVMS
configuration procedure autoconfigures the DECdts clerk. If your
network uses multiple DECdns servers, or if you need network clock
sychronization, DIGITAL recommends that you install at least three
DECdts servers on each LAN. See the DECnet-Plus DECdts Management guide for more
1.3.4 Intermediate System
In large networks and networks requiring high throughput, one or more
dedicated routers are recommended for the network. DIGITAL recommends
using host-based routers to replace DECnet Phase IV host-based routers
or in environments not requiring high throughput.
The DECnet-Plus for OpenVMS VAX systems license includes the right to use X.25 Access software (formerly known as VAX P.S.I. Access) or X.25 Native mode software (formerly known as VAX P.S.I.), which requires an additional license.
The X.25 software in DECnet-Plus for OpenVMS is backwards compatible with systems running the older VAX P.S.I. products. For further information on X.25, refer to Chapters 2 and 4.
On DECnet-Plus for OpenVMS Alpha systems, the following licenses are required:
To develop OSI applications, you need to use the OSI application development interfaces (API) installed with the base system. These tools allow you to build network applications that adhere to the OSI standards defined by the International Organization for Standardization (ISO).
You can use the following components in building OSI applications:
Where ISO standards exist, the APIs conform to these standards.
The following table shows the components available on DIGITAL UNIX and OpenVMS platforms.
|DIGITAL UNIX||FTAM, OSAK (Presentation and ACSE)|
|OpenVMS||FTAM, OSAK (Presentation and ACSE), ROSE (VAX only)|
A DECnet-Plus network can be viewed as a distributed processing system. The major functions of the network, such as network management and routing, are not centralized in a single system. Each system can manage both itself and remote systems. Adaptive routing eliminates the need to set up network data paths.
Some of the primary features of the DECnet-Plus distributed network are:
Networkwide capabilities include the optional use of distributed system services designed to make the network as transparent as possible to users and applications. The DECnet-Plus distributed computing environment provides the following services:
In the DECnet-Plus distributed processing environment, you can physically distribute multiple resources or tasks that perform various functions between systems on the network.
A distributed application is a collection of processes that use resources, such as processing elements, databases, and physical devices, located on other systems in the network. As a single logical application, the elements or tasks are physically divided. A task is a modular component of work that the application programmer defines within an application. The work of a distributed application is divided among tasks that can communicate with each other.
In an OpenVMS operating system, a task is executed within the context of a process. The process context defines the environment in which the task executes. OpenVMS software controls the access and allocates the resources required by the task, based on the process context.
In a distributed application, each task is distinct and can be placed in different locations in the network. The system interface for the application allows you to run the application locally or remotely without any apparent difference.
You can distribute an application so that each task is assigned to a system with appropriate resources. For instance, one task computes on a powerful processor while another stores the information in a database on a system with extensive disk storage capabilities. A common example of a distributed application is an implementation of the client/server model, such as DECdns, in which the client task (on the DECdns clerk system) requests service from the server task on a different system (the DECdns server).
Interprocess communication is the movement of data and control from one task running within a process to another task in the network. Interprocess communication allows the various tasks on the different processes to cooperate and communicate with each other, exchanging message packets over the connection established between the tasks.
Distributed applications can increase availability. You can design a distributed application to avoid a single point of failure by moving tasks to other processors if a processor fails. Other benefits of distributed applications include:
An OpenVMS cluster configuration is an organization of OpenVMS
operating systems that communicate over a high-speed communications
path and share processor resources as well as disk storage. DECnet
connections are required for certain OpenVMS cluster tools and
configurations. DECnet-Plus for OpenVMS software provides support for
OpenVMS cluster systems.
1.5.1 DECnet-Plus OpenVMS Cluster Alias
DECnet-Plus for OpenVMS supports the use of multiple cluster aliases. The alias node identifier (a node name or node address) is common to some or all nodes in the cluster and permits users to address it as though it were one node.
For management purposes, the cluster alias is viewed by the DECnet-Plus software as a separate Node entity that is manageable through NCL commands. The Alias entity differs from a regular Node entity in some characteristics; for example, the Alias entity does not support a Circuit entity. The cluster alias appears to the network as a multicircuit end node, which is an end node with several active circuits. In an OpenVMS cluster system that consists of DECnet-Plus for OpenVMS systems on a LAN, the alias node appears as an end node with multiple points for attachment to the LAN.
DECnet-Plus for OpenVMS supports the ability to access nodes in an
OpenVMS cluster 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. The maximum
number of nodes supported for a cluster alias is 96. The maximum number
of cluster aliases for a single node is three.
1.5.2 OpenVMS Cluster Configuration Procedure
The cluster_config.com command procedure for performing a OpenVMS cluster configuration invokes the DECnet-Plus for OpenVMS net$configure.com command procedure to perform any required modifications to NCL initialization scripts. Use cluster_config.com to create a configuration for each satellite node in the cluster.