DECnet-Plus for OpenVMS
Introduction and User's
DECnet-Plus for OpenVMS Components
2.1 Features of DECnet-Plus for OpenVMS
DECnet-Plus for OpenVMS is an implementation of Phase V of the DIGITAL
Network Architecture (DNA) for the OpenVMS operating system.
DECnet-Plus integrates DECnet and OSI network protocols allowing both
stacks to share integrated network functions up to the Transport layer.
Upper layers have been implemented as separate "towers," allowing
existing DECnet and OSI applications to share the integrated Transport
layer. Existing DECnet Phase IV and new DECnet and OSI applications are
supported by DECnet-Plus. In combination with TCP/IP protocol stacks,
OpenVMS systems can participate in multivendor, multiprotocol networks
adhering to Open Networking standards.
For details on specific upgrades and enhancements, refer to the
DECnet-Plus for OpenVMS Release Notes.
Refer to Figure 2-1, which illustrates the integrated DNA Phase V
Figure 2-1 DNA Phase V DECnet-Plus for OpenVMS
2.1.1 OpenVMS Software Components
DECnet-Plus for OpenVMS offers task-to-task communications, file
management, and downline system and task loading. Network WAN
connectivity is provided by WAN device drivers supporting host-based
synchronous communications options for wide area networking.
DECnet-Plus for OpenVMS is available in two forms: End System and
Extended Function. Extended Function provides all the features of End
System plus the OSI application gateways (FTAM--DAP Gateway, VT-Telnet,
LAT/VT and VT/LAT), the DECdns server (on VAX platforms), and
host-based routing, and cluster alias.
The functions offered by OpenVMS are split into separate components.
The entire base system installs automatically when you start the
installation procedure, while the additional components are optionally
installable. To support open, standards-based, multiprotocol
communications, DECnet-Plus for OpenVMS is comprised of the DECnet-Plus
base system (including DECdns and DECdts clerk software), and the
following optional software:
- DECdts server---Software that synchronizes the system clocks in
computers connected by a network.
- WAN device drivers---Software that links a hardware device and
layered software for synchronous communications over wide area networks.
- X.25---Allows suitably configured DECnet-Plus systems to connect to
Packet Switching Data Networks (PSDNs) conforming to CCITT
recommendation X.25 (1980 or 1984) and/or to International Standards
(ISO) 7776 and 8208. This allows a DECnet-Plus system to function as
data terminal equipment (DTE) or be addressed as data circuit
terminating equipment (DCE). On Alpha systems, X.25 is obtained
separately from the DECnet-Plus software kit.
- Open System Application Kernel (OSAK) software---DIGITAL's
the OSI network architecture components that provide services for OSI
- File Transfer, Access, and Management (FTAM) software---DIGITAL's
that allows you to perform file operations between OSI-compliant
- DAP--FTAM gateway---Allows your DECnet-Plus node to participate in
an OSI network in a simplified manner; for example, you can issue DCL
commands to communicate with remote OSI systems through the gateway.
Communication with a remote FTAM application is handled the same as any
- Virtual Terminal (VT)---DIGITAL's OSI application that enables
application and systems supporting different types of terminals to
interoperate with each other. Using VT, you can use your terminal to
access any other system running VT, regardless of the type of system.
You can also use the VT gateways for access to and from non-OSI systems.
- LAT/VT and VT/LAT gateways---Allows connections between a LAT
terminal and OSI systems.
- VT/Telnet and Telnet/VT gateways---Allows communications between
OSI and Internet systems.
Table 2-1 lists the functions of DECnet-Plus for OpenVMS matched
with the specific software components that you need to install and/or
configure during the DECnet-Plus for OpenVMS installation procedure.
Other dependencies are also noted.
Table 2-1 Functions and Associated Software
||Software (and other dependencies)
OSI Transport Service classes 0, 2, 4 (TP 0, TP 2, TP 4)
Base system (configuration of OSI Transport software)
RFC 1006 Extension (Internet Draft)
Base system (configuration of OSI Transport software) TCP/IP software
ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC
Base system (and, to communicate beyond the local subnetwork, a
DECnet-Plus-compliant intermediate system)
File operations to and from remote OSI systems
FTAM, OSAK software
VT to OSI systems
VT, OSAK software
Function as OSI end system
FTAM, VT, DIGITAL-provided OSI application, or customer-written
Run any OSI application
other than FTAM, VT
ACSE Presentation and Session
OSAK server (inbound connection handler)
WAN X.25 communications on local system
WAN X.25 communications via a connector node+
LAN X.25 communications (LLC2)
DECnet-Plus for OpenVMS network management
Network management support tools
Node-name management support tools
FTAM and VT gateways
Gateways software (included in FTAM), Extended Function license; for
Telnet/VT gateway, also DIGITAL TCP/IP Services for OpenVMS
DECdns clerk, DECdts clerk
+The connector node can be a DECNIS router 500 or 600, or X.25
configured in multihost mode.
2.2 DECnet-Plus for OpenVMS Base System
The DECnet-Plus for OpenVMS base system software allows an OpenVMS
system to perform as both a DECnet end node and an OSI end system. It
can communicate using ISO 8802-3 (CSMA-CD) or ISO 8802-5 (FDDI)
broadcast lines, either DIGITAL Data Communications Message Protocol
(DDCMP) or point-to-point through HDLC lines.
The DECnet-Plus base software offers the following features:
- End system implementation of the first four layers of the OSI
Reference Model and all the layers of DNA
- Host-based routing (that replaces DECnet Phase IV routing vector
host-based environments not requiring high throughput)
- Application, Presentation, and Session layers
- File Transfer, Access, and Management (FTAM) application
- Virtual Terminal (VT) application
- Application Service Elements (ASEs), including ACSE (Association
Control Service Element)
- DNA Session Control layer (see Section 3.5)
- Interprocess Communication ($IPC) programming interface
- Queue Input/Output ($QIO) programming interface
- Common Management Information Service Element (CMISE) programming
- Support for DNA-based, DIGITAL and user applications
- Transport layer, classes 0, 2, 4 (see Section 3.6)
- OSI Transport Service
- DIGITAL Network Services Protocol (NSP) Transport Service
- RFC 1006 and RFC 1006 Extension (Internet Draft)
- Lower layers
- OSI addressing formats, supporting very large network topologies
- End-system-to-intermediate-system (ES-IS) routing
- Connectionless-mode Network Service (CLNS) over local area network
(LAN), wide area network (WAN), and X.25
- Logical link control type 2 (LLC2) for Connection-Oriented Network
Service (CONS) over LAN
- Network layer (see Section 3.7)
- OSI-compliant addressing formats; virtually unlimited network size
- ES-IS routing
- CLNS which supports OSI Transport class 4 over ISO 8802-3 and X.25
- Internetwork Protocol to support CLNS
- CONS which supports OSI Transport classes 0, 2, and 4 over ISO
8802-3 and X.25 connections
- Data Link layer (see Section 3.8)
- Supports High-level Data Link Control (HDLC) for wide area
communications, ISO 8802-3 (Ethernet CSMA-CD) and FDDI LANs, and
DIGITAL Data Communications Message Protocol (DDCMP) for backwards
compatibility. HDLC support includes the Link Access Protocol Balanced
(LAPB) protocol for X.25 communications.
- ISO 8802-2 logical link control type 1 (LLC1)
- FDDI driver support
- Physical layer (see Section 3.9)
- CSMA-CD, HDLC, and FDDI devices supported
- Network management (see Section 3.10)
- Network management support tools (see Section 2.8)
- Node-name management support tools (see Section 2.8)
2.2.1 DECnet Over TCP/IP
The DECnet over TCP/IP feature allows users to run standard DECnet
applications in an Internet Protocol (IP) routing environment.
When you are running DECnet over TCP/IP, you can connect using an IP
address, for example:
$ set host node.site.company.com
The connection is made using the DNA CTERM application instead of the
TCP application FTP. Note that both the source and target nodes must
support DECnet over TCP/IP for this connection to work. The system can
be configured to allow you to use synonyms (Phase IV-style names)
instead of the IP host full name. If a system does not run DECnet and
support DECnet over TCP/IP, you need to use COPY/FTP to access that
system. For example:
For more information on running DECnet over TCP/IP, refer to the
DECnet-Plus Network Management and the installation and
configuration guides. This feature requires any valid DECnet license
and a licensed and installed TCP/IP product that supports the PATHWORKS
Internet Protocol (PWIP) interface.
2.2.2 DIGITAL-Supplied Session Control Applications
A DECnet Phase IV "object" in DECnet-Plus is called an
application. The DECnet-Plus for OpenVMS base system
supplies the following session control applications, which are defined
automatically at network startup:
- Task --- Image that provides full Phase-IV compatibility.
- File Access Listener (FAL) --- Image that provides authorized
access to the file system of a DECnet-Plus system on behalf of
processes executing on any network system. FAL communicates with the
initiating system by means of the Data Access Protocol (DAP).
- CMIP Management Listener (CML) --- Image that allows remote
management of the local system.
- Loopback mirror (MIRROR) --- Image used for some loopback testing.
- OpenVMS Mail --- Image that provides mail service for DECnet-Plus
for OpenVMS systems.
- OpenVMS Phone --- Image that allows you to communicate with other
users on your system or with any other connected DECnet-Plus system.
- OpenVMS Cluster Performance Monitor (VPM) Server --- Image used to
run Open VMS Cluster monitoring features of the Monitor utility
2.2.3 Programming Interfaces
The DECnet-Plus for OpenVMS base system offers the following
- Common Management Information Element Service (CMISE) interface
DECnet-Plus for OpenVMS CMISE application programming interface
provides the mechanism for user-written applications to perform OSI
network management, and implements the ISO 9595 Common Management
Information Service specification on OpenVMS. Two cooperating
management applications in an OSI network are known as CMISE service
users. These service users establish an association and exchange
management information by means of the CMISE interface.
interface provides three types of management services:
- Management Association Services for the establishment and release
of associations between service users
- Management Operation Services for the transfer of management
information between service users
- Management Notification Services for the reporting of events
between service users
- Interprocess Communication ($IPC) interface
OpenVMS $IPC system service is an OpenVMS operating system interface to
the Session Control layer that can be used to perform interprocess
communication. This interface is a standard OpenVMS system service
With the $IPC system service, distributed applications can
run in a variety of environments without modification. $IPC operates
over both local area and wide area connections. $IPC provides for
efficient communication within a single DECnet-Plus for OpenVMS system,
and between a DECnet-Plus for OpenVMS system and any other system
running DECnet-Plus software in either a DECnet-Plus or multivendor
$IPC provides basic connection, data transfer,
and information management services. It permits an association to be
opened between the application and the DNA Session Control layer. The
$IPC interface can then create or accept connections over the opened
association. $IPC can receive and process multiple inbound connection
requests destined for a single application.
Connection to the
remote target can be made through specification of:
- The DECdns object name of the target application, if your network
uses the distributed DECdns namespace. For this connection, Session
Control transparently selects the protocol tower information to be used
based on the protocol and address information supplied by DECdns for
the application service.
- Protocol towers for the target application (as stored in the
DNA$Towers attribute) that specify which address and protocol
is to be used to communicate with the application.
- A Phase IV or DECnet-Plus node name and application identification.
(The target application can be identified by the internal version of a
DECnet-Plus full name properly formatted for the Local namespace on
DECdns or by a Phase IV object number or task name.)
The primary functions of $IPC include:
- Connection setup services --- Opens an association between an
application and Session Control and declares an application name for
incoming connections. (Also performs the function of shutting or
- Connection services --- Requests a logical connection to a target
task, identifying the target application in the connect initiate
- Control services --- Receives incoming connect initiate requests,
associates the requests with the calling process, and accepts or
rejects the connection. (Also disconnects or aborts connections.)
- Data transfer services --- Transmits and receives messages,
including expedited data messages (messages that bypass flow control
mechanisms). Receives unsolicited network events, such as third-party
- General services for managing information about the system and
connections --- Resolves names, obtains information about a current
connection, enumerates local towers, and supports backward translation
of an address.
- Queue Input/Output ($QIO) interface
DECnet-Plus for OpenVMS
continues to support transparent and nontransparent task-to-task
communications applications that use $QIO system service calls in the
same way as for Phase IV. If a 6-character limit on node names is
encoded in the Phase IV application, use a Phase IV-style node synonym
for both incoming and outgoing connections.
DECnet-Plus for OpenVMS supports $QIO calls that are specifically
required for applications coded to the OSI Transport Service.
- Remote Access Interfaces
With DECnet-Plus for OpenVMS, you can
perform network operations as a natural extension of the input/output
operations on the local system. In addition, a DECnet-Plus for OpenVMS
programmer can write command procedures and programs that make the
network transparent to users.
You can access remote files and tasks
using DCL commands and command procedures, higher-level language
input/output statements, or OpenVMS Record Management Services (RMS).
For example, programs written in COBOL, C, Ada, MACRO, Fortran, BASIC,
Pascal, or PL/1 can access remote files.
2.2.4 OSI Transport Service
A DECnet-Plus for OpenVMS system functions as an OSI end node if,
during configuration, you configure OSI Transport. An application can
set up a transport connection to another application on any other
system, either DIGITAL or multivendor, running software that implements
the OSI Transport Protocol.
2.2.5 NSP Transport Service
DECnet-Plus for OpenVMS software includes the Network Services Protocol
(NSP) for DECnet Phase IV compatibility. You can use the proprietary
NSP and the open OSI Transport Protocols simultaneously.
18.104.22.168 End-System-to-Intermediate-System (ES-IS) Routing
The ISO End-System-to-Intermediate-System (ES-IS) Routing Exchange
Protocol provides the process by which end systems communicate with
intermediate systems (routers), or with each other, to exchange
You can configure a LAN with all end systems. In end-system-only
configurations, the DECnet-Plus systems use ES-IS routing to
communicate directly with each other. They use a specific multicast
address to which all end systems listen. With this routing process, the
concept of adjacency does not exist.
2.2.6 Network Management
DECnet-Plus network management offers the following benefits:
- Consistency across the DIGITAL Network Architecture (DNA), which in
turn allows products developed by different sources to be managed in a
- A modular design, which allows systems to be as simple or as
complex as appropriate to the services they provide their users.
- Extendibility, which allows new functions to be added to DNA and
managed consistently with existing functions.
You can perform the following network management functions:
- Controlling the network
- Providing host services to other DECnet-Plus systems
- Providing host services to DECnet Phase IV nodes
- Establishing DECnet-Plus configurations
Section 3.10 introduces the concepts of DECnet-Plus network management.
2.2.7 Name Service
The DECnet-Plus Session Control layer requires a name service to map
node names to addresses. A DECnet-Plus network can use one namespace
exclusively, or it can have a mixture of systems using the Local
namespace, the DECdns distributed namespace, and/or DNS/BIND.
DECnet-Plus provides access to the node name and addressing information
stored in one or more of the following name services:
- The Local namespace is a discrete, nondistributed
namespace that stores name and address information locally in database
files. It maintains a database of names and addresses on the local
node. Use a Local namespace if you decide not to use a distributed
namespace, or if you decide to delay full planning and implementation
of a distributed namespace. The Local namespace is designed to scale up
to at least 100,000 nodes depending on the number of address towers
- The DIGITAL Distributed Name Service (DECdns)
software is a distributed, global name service that allows users and
applications to assign unique names to resources and then use these
resources without knowing their physical location.
each DECnet-Plus for OpenVMS system that does not use a Local namespace
will be configured as a DECdns clerk. DECdns clerks request servers to
provide address mapping for them. Because DECnet-Plus for OpenVMS does
not contain DECdns server software, servers running on DIGITAL UNIX or
OpenVMS systems must handle clerk requests.
The DECnet-Plus for
OpenVMS configuration procedure autoconfigures the DECdns clerk
- The Domain Name System (DNS/BIND) is the
distributed name service for TCP/IP and supports the storage of IP
addresses. In addition, support for DNS/BIND provides for the use of
node synonyms. This allows for backward compatibility with older
applications that cannot use long domain names.
There are two ways
to configure node synonyms for use with DNS/BIND:
- By constructing an appropriate set of naming search path templates.
- By defining local aliases.
While configuring DECnet-Plus, the system administrator specifies one
or more of the following name services to use on the node: the Local
namespace, DECdns, or Domain (for DNS/BIND).
DECnet-Plus includes a new in-memory naming cache to improve
performance of name and address resolution for all supported name
DECnet-Plus includes features to ease namespace management including
decnet_register (a namespace management tool), numerous NCL
commands, and Common Trace Facility (CTF) support for monitoring node
name and address resolution. In some instances, this simplified access
to multiple name services is referred to as CDI or the common directory
In addition to the Local namespace and DECdns, for node-name-to-address
mapping your network can use, if it has one, an existing VAX
Distributed Name Service (DNS) Version 1 namespace.