[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS System Manager's Manual


Previous Contents Index

21.2.2 DECnet-Plus for OpenVMS Software Components

DECnet-Plus comprises a base system and optional components. The base system of components installs automatically when you start the installation procedure. Base system components include:

The following components are optionally installable:

21.2.3 Dependencies and Licenses

To use DECnet-Plus for OpenVMS or DECnet Phase IV software, you need the appropriate software licenses. Table 21-3 lists the two basic licenses (end system and extended function) and three license keys for OpenVMS VAX and Alpha systems, for DECnet Phase IV and DECnet-Plus, respectively.

Table 21-3 DECnet Phase IV and DECnet-Plus Licensing
VAX Phase IV VAX DECnet-Plus Alpha Phase IV Alpha DECnet-Plus
End System License
DVNETEND DVNETEND DVNETEND DVNETEND
All DECnet Phase IV functionality except cluster alias and routing All DECnet-Plus 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
DVNETRTG DVNETRTG DVNETEXT DVNETEXT
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, 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, host-based routing 3


1Application programming interface
2The DVNETRTG license is required on one node in the cluster to enable cluster alias
3Host-based routing is available on DECnet-Plus (Version 7.1); it was not available on DECnet Phase V (DECnet/OSI) systems before Version 7.1
4Routing is not supported on DECnet Phase IV OpenVMS Alpha systems

21.2.4 Preparing to Join a Network

Before configuring your DECnet-Plus node, you must make some decisions regarding addressing, the use of name services, time services, and routers. You must also be aware of license dependencies unique to X.25 software. The following sections provide more information.

21.2.4.1 Network Addressing

If your users on the DECnet-Plus network need the ability to communicate with users on other OSI networks, either through electronic mail, EDI, FTAM, VTP, or other internetwork utilities, you must obtain from an authorized authority such as ANSI, a unique network identifier called a new domain part (IDP). This is a part of the NSAP.

If your users do not need to communicate with others on OSI networks, a default IDP is provided with DECnet-Plus that you can use at configuration time. For more information about addressing, refer to DECnet-Plus Planning Guide.

21.2.4.2 Selecting a Name Service

For mapping between node names and node addresses, you need at least one of the three name services: Local namespace, DECdns, or DNS/BIND. 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, see the table below or 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.
Name Service When to Use
Local Namespace With small networks with no need to use a distributed namespace (name mapping is administered separately on each node.) Local namespace is similar to the permanent node database (NETNODE_REMOTE.DAT), used on DECnet Phase IV systems. To use the Local namespace, no additional software is required.
DECdns With larger networks, with the need to administer and store node names from one location. Two or more servers running DECdns software are required. The DECdns server software is optional software included with the DECnet-Plus for OpenVMS software kit. For more information, refer to
  • DECnet-Plus Planning Guide
  • DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration
  • DECnet-Plus DECdns Management
DNS/BIND When running DECnet-Plus applications over TCP/IP.

DNS/BIND supports the storage of IP addresses and the use of node synonyms that allow for backward compatibility with older applications that cannot use long domain names. DECnet-Plus requires one or more DNS/BIND servers in the network. Refer to the appropriate TCP/IP documentation for more information about DNS/BIND.

21.2.4.3 Selecting DECdts Time Servers

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, Compaq recommends that you install at least three DECdts servers on each LAN. Refer to the DECnet-Plus DECdts Management guide for more information.

21.2.4.4 Setting Up Routers

In large networks and networks requiring high throughput, one or more dedicated routers are recommended for the network. Compaq recommends using host-based routers only to replace DECnet Phase IV host-based routers or to route in environments not requiring high throughput.

21.2.4.5 X.25 Licenses and Dependencies

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). The right to use X.25 Native Mode software (formerly known as VAX P.S.I.) 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 about X.25, refer to DECnet-Plus for OpenVMS Introduction and User's Guide.

On DECnet-Plus for OpenVMS Alpha systems, the following licenses are required:

21.2.4.6 Running DECnet or OSI Over TCP/IP

If you plan to use the DECnet over TCP/IP feature or the OSI over TCP/IP feature on OpenVMS systems, TCP/IP software is a prerequisite. The TCP/IP software used on your system must support the PATHWORKS Internet Protocol (PWIP) interface.

21.2.5 DECnet-Plus Node Names

Naming conventions for DECnet node names correspond to the two types of DECnet functionality:

Syntax for Full Names

Full names have the following general syntax:

namespace:.directory ...  .directory.node-name    

where:
namespace Identifies the global name service
directory ... .directory Defines the hierarchical directory path within the name service
node-name Is the specific object defining the DECnet node

The following examples show node full names for the Local namespace, DECdns, and DNS/BIND, respectively:


 Local namespace -  LOCAL:.CPlace 
 DECdns          -  ACME:.warren.CPlace 
 Domain          -  CPlace.warren.acme.com 

The system stores a full name as you enter it, preserving uppercase and lowercase entries. However, when matching an entry with a stored full name, the system is case insensitive; in other words, if the user enters Acme, the system recognizes it as equivalent to ACME.

For more information about full names, refer to the DECnet-Plus documentation.

21.2.6 Support for OpenVMS Cluster Systems

DECnet-Plus for OpenVMS software continues support for OpenVMS Cluster systems and the use of OpenVMS Cluster aliases. DECnet-Plus allows for three aliases for each OpenVMS Cluster. DECnet Phase IV nodes cannot be DECnet-Plus alias members. A separate alias must be configured for use with DECnet Phase IV nodes.

The CLUSTER_CONFIG.COM command procedure performs an OpenVMS Cluster configuration. It can configure all members of a cluster from any cluster member. It 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 configure an OpenVMS Cluster. Use NET$CONFIGURE.COM directly to configure additional DECnet-Plus satellite nodes once CLUSTER_CONFIG.COM has already been used.

21.2.7 Configuring DECnet-Plus

The NET$CONFIGURE.COM configuration procedure offers you three options for configuring DECnet-Plus. Table 21-4 reviews these options.

Table 21-4 DECnet-Plus Configuration Options
Option When to Use
FAST For quick configuration when:
  • You want your DECnet-Plus (Phase V) system to operate in the same way as a DECnet Phase IV system.
  • You are not completely familiar with the DECnet-Plus product and are upgrading a DECnet Phase IV node to DECnet-Plus.

The DECnet-Plus system configures itself by determining the Phase IV and OpenVMS operating system parameters. The local namespace is used for naming information. You can reconfigure the system at a later time to include additional functionality.

The FAST option is not supported on a node that is running in an OpenVMS Cluster or on a node that is a DECdns server.

BASIC You plan to accept defaults for most components but want to customize a few, for example:
  • Communications device or multiple communications devices used for DECnet-Plus communications
  • Names for all devices and routing circuits
  • Autoconfigure your network addresses
For more information, refer to DECnet-Plus for OpenVMS Installation and Basic Configuration.
ADVANCED For customizing your system's network configuration, such as to:
  • Use DECnet-Plus over TCP/IP or OSI over TCP/IP
  • Support multiple communications devices with a mix of protocols
  • Add more flexibility in how you run X.25 services
  • Specify your own names for certain network components rather than accepting the defaults
  • Configure DECnet-Plus for OpenVMS VT, OSAK, and/or FTAM software
  • Configure your system as a DECdns server
  • Configure your own NETs rather than have them autoconfigured
For more information, refer to DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration.

You can also use NET$CONFIGURE.COM to reconfigure all or individual entities of the local DECnet-Plus for OpenVMS system. Rerunning the configuration procedure modifies or replaces relevant initialization script files but does not affect running systems. You then execute the modified initialization script files to effect these changes.

The initialization scripts create and enable all required entities. Each entity is initialized through execution of a separate NCL script file. Using NCL scripts to initialize DECnet-Plus for OpenVMS systems replaces the Phase IV requirement of establishing a DECnet permanent configuration database at each node. Remote node information resides in either a local or distributed namespace (DECdns or DNS/BIND).

For further information, refer to the DECnet-Plus Network Management guide.

21.2.8 Moving Your Phase IV Network to DECnet-Plus

If you are involved in transitioning your network from DECnet Phase IV to DECnet-Plus, you may choose to move portions of a network, or the entire network, from DECnet Phase IV to DECnet-Plus. Remember that DECnet-Plus is backward compatible, meaning that you can choose to run your system and the network in the same manner as you have before, using DECnet Phase IV applications, routing, and so forth. You can implement the additional functionality available to you from DECnet-Plus any time you are ready. The changes mostly involve network management. They are almost entirely transparent to users and applications.

A number of automated tools (DECnet transition utilities and the NCP Emulator) are available, in addition to the simplified configuration procedures, to help ease the transition to full DECnet-Plus functionality.

The DECnet-Plus Planning Guide details steps for transitioning your network.

21.2.9 Network Management Tools

DECnet-Plus for OpenVMS provides network tools that let you:

21.2.10 Network Management Tasks

The primary network management tasks include the following ones:

The following sections briefly describe these tasks. Refer to the DECnet-Plus for OpenVMS Introduction and User's Guide for instructions on using management tools and the DECnet-Plus for OpenVMS Network Management guide for complete information about maintaining, controlling, shutting down, and restarting the network. The DECnet-Plus Problem Solving guide includes information for testing and troubleshooting.

21.2.10.1 Providing Security for Your Node

DECnet-Plus regulates access to the network on various levels, including the following levels:

The following sections describe these levels of control.

Required Rights Identifiers

DECnet-Plus for OpenVMS uses OpenVMS rights identifiers to perform access checks on all manageable entities. This differs from the Phase IV software, which used OpenVMS privileges for access to the permanent database and for write access. Read access to the volatile database in Phase IV was unprotected.

In DECnet-Plus for OpenVMS, three rights identifiers allow the network manager to restrict access to network parameters. Access is granted to an individual user by means of the Authorize utility AUTHORIZE on OpenVMS. These are used as follows:
Rights Identifier Access Granted
NET$EXAMINE Read access to the network configuration data. For example:
UAF> grant/id net$examine Joe

NET$MANAGE Read and write access to the network configuration data. For example:
UAF> grant/id net$manage Joe

NET$SECURITY Ability to set default accounts. For example:
UAF> grant/id net$security Joe

In lieu of NET$MANAGE rights, the BYPASS privilege will grant read and write access.

Access Control

Whenever a DECnet node attempts to connect to a remote DECnet-Plus node, it sends access control information to the Session Control entity on the remote node. Access control allows you to control connections between nodes. Access control information can come from a number of sources. The following list shows the hierarchy of access control from highest to lowest priority. Refer to the DECnet-Plus for OpenVMS Network Management guide for details.

  1. The network user on the local node can explicitly supply access control information, such as in the following example:


    $ MCR NCL SHOW NODE CPLACE"NOWAK QUICKONE" ALL 
    

    In this case, the remote node uses the access control information.

  2. If no explicit access control information has been provided, the local node checks to see if outgoing proxy access is enabled for a local node or an application. If the proxy is enabled, the local node initiates a connection and the Session Control entity on the remote node determines if the initiating user has proxy access.
  3. When the remote node sees that no explicit access control has been specified and that no proxy matches, it checks its application database. If the database contains an application user name, it uses that name.
  4. If no default application user name exists in its application database, the remote node checks its Session Control entity attributes for default nonprivileged DECnet user name information. If the information is there, the remote node uses the default nonprivileged DECnet user name.
    The default DECnet user name allows users to perform certain network operations, such as the exchange of electronic mail between users on different nodes, without having to supply a user name and password. The default DECnet user name is also used for file operations when access control information is not supplied. For example, it permits remote users to access local files on which the file protection has been set to allow world access. If you do not want remote users accessing your node, do not create a default DECnet user name.

Finally, if none of these sources supply valid access control information, the connection fails.

Note

In DECnet-Plus, "nonprivileged" means having NET$DECNETACCESS rights and TMPMBX and NETMBX privileges. These are the minimal rights and privileges necessary for any network activity. "Privileged" means any rights and privileges in addition to NET$DECNETACCESS rights and TMPMBX and NETMBX privileges.

In Phase IV, "nonprivileged" means NETMBX and TMPMBX privileges only. NETMBX and TMPMBX are the minimal requirement for any network activity. "Privileged" means any privileges in addition to NETMBX and TMPMBX.

You can check if there is a default nonprivileged user name for Session Control by issuing the following command:


ncl> show session control non privileged user   

You can check if there is a default nonprivileged account for applications by issuing the following command:


ncl> show session control application fal user name   

You can use NET$CONFIGURE.COM to establish the default nonprivileged DECnet account and directory for you automatically. You can also add a default nonprivileged DECnet account manually, as explained in the DECnet-Plus for OpenVMS Network Management guide.

Note

You do not need to use access control information when a connection to a program has declared an application name and has started independently of DECnet. Instead, you need NET$DECLAREOBJECT rights to declare that you want to accept incoming connections.

Specifying Routing Initialization Passwords

The DECnet-Plus for OpenVMS Network Management guide explains how to set up a routing initialization password.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6017PRO_089.HTML