To determine the OpenVMS operating system version number, enter the following DCL command:

$ show system

If you plan to use the DECnet-Plus over TCP/IP feature, then TCP/IP software is a prerequisite. Your system will be able to operate over TCP/IP if and only if the TCP/IP product used on your system supports the PATHWORKS Internet

Protocol (PWIP) interface. For more information about required TCP/IP software, see the DECnet-Plus for OpenVMS Release Notes.

To determine if a DECnet-Plus license is registered, enter the following DCL command:

$ show license dvnet* 

If the system does not have the required licenses, obtain the Product Authorization Key (PAK) and register the license. For instructions on registering a license, refer to the VSI OpenVMS License Management Utility Guide.

If this is the first time you are installing DECnet-Plus on a particular system, ensure that you have enough free space on the system disk. You need enough space to install the DECnet-Plus Base components and any options you select.

If you already have DECnet-Plus installed, you need considerably less free space for the installation because the earlier installation has already allocated most of the space that a subsequent installation needs.

Table 1.1, “DECnet-Plus Disk Space Requirements” shows the amount of disk space needed to install the DECnet-Plus software components. Make sure you have enough free space to install the required software and the optional software.

To find out how many free blocks exist on the system disk, enter the following command:

$ show device sys$sysdevice 

If the number of required blocks exceeds the number of free blocks, you must clear space on the system disk.

The minimum amount of memory required is 512 MB for OpenVMS I64 systems, 64 MB for OpenVMS Alpha systems, and 24 MB for OpenVMS VAX systems.

To check the amount of memory on your system, enter the following command:

$ show memory/full 

This section provides information about system parameters, their values, and how to modify them.

Table 1.2, “Minimum System Parameters Required — Base Software Installation” lists the minimum system parameters required for the base software.

In addition to the minimum system parameter values, DECnet-Plus also requires several ADD_ parameter values to ensure adequate resources are available.

These values are listed in Table 1.3, “ADD_ System Parameter Values”.

To check any system parameter, invoke the SYSGEN utility and enter the show command. For example, to view the current value for GBLSECTIONS, enter the following command:

$ mcr sysgen
SYSGEN> show gblsections

If any of the system parameters need to be modified, follow these steps:

HP recommends that you install and configure DECnet-Plus from the SYSTEM account. If you are configuring from another account, make sure the account has the following privileges and rights identifiers in place before you begin.

Required account privileges are as follows:

Required rights identifiers are as follows:

$ show process/privileges

To start the installation, follow these steps:

You are then prompted for installation information as in the following example. In this example, numbered callouts (, , , ...) guide you through the sequence of steps that require your response.

Performing product kit validation ...
%PCSI-I-VALPASSED, validation of
DKB500:[KITS]DEC-AXPVMS-DECNET_OSI-V0803--1.PCSI$COMPRESSED;1 succeeded

The following product has been selected:
   DEC AXPVMS DECNET_OSI V8.3 Layered Product

 Do you want to continue? [YES]

Configuration phase starting ...

You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.

DEC AXPVMS DECNET_OSI V8.3: DECnet-Plus V8.3 for OpenVMS AXP

VSI I64VMS DECNET_PLUS V8.3: DECnet-Plus V8.3 for OpenVMS I64
   Copyright © 2020 VMS Software, Inc., (VSI). All rights reserved.
   VMS Software, Inc.

This product requires one of two PAKs: DVNETEND or DVNETEXT.

 Do you want the defaults for all options? [YES] NO

Do you want to change any options? [YES]

   DEC AXPVMS VMS V8.3 [Installed]
   * Configuration options for this referenced product cannot
   * be changed now because the product is already installed.
   * (You can use PRODUCT RECONFIGURE later to change options.)

   DECdns Server software [NO] YES

   DECdts Server software [NO] YES

 Do you want to review the options? [NO]

Execution phase starting ...

The following product will be installed to destination:
   DEC AXPVMS DECNET_OSI V8.3 DISK$XBAJ:[VMS$COMMON.]

Portion done: 0%...10%...20%...30%...40%...50%...80%...90%...100%

The following product has been installed:
   DEC AXPVMS DECNET_OSI V8.3 Layered Product
$

The net$configure procedure deletes all of your local and global symbols at the beginning of the procedure in order to free the symbol table. This action is required because net$configure creates and uses a large number of symbols. If the symbols were not deleted at the beginning of the procedure, net$configure could run out of symbol table space to use while configuring the system. In most cases, the configuration procedure restores your symbols as it exits.

Although net$configure can be run simultaneously on different nodes in a cluster, it should not be run simultaneously from different processes on the same node.

DECnet-Plus provides access to the node name and addressing information stored in one or more name services. DECnet-Plus supports the following directory name services:

The sections that follow give a short introduction to each of the name services. For more information on name services, refer to the VSI DECnet-Plus Planning Guide.

* Enter the directory services to use on the system [DECdns,Local,Domain] :

After requesting the ordered list of directory name services, the configuration procedure prompts you for one or more node full names. You can enter a DECdns full name, a Local namespace full name, a fully qualified host name for the Domain Name System (DNS/BIND), or all three.

Use the following guidelines for selecting a node full name:

The following are some examples of suitable node full names:

Local namespace - LOCAL:.TomThumb
DECdns          - ACME:.wabbit.Elmer
Domain          - elmer.wabbit.acme.edu

You should plan node full names carefully and make sure they are unique within the namespace. If your network administrator has not assigned a unique node full name for your system, be sure to read the VSI DECnet-Plus Planning Guide before you assign a node name for your system.

The prompts used by the configuration procedure depend on the directory name services you entered. For example, if you enter LOCAL,DECDNS,DOMAIN at the directory services prompt, the configuration dialog asks for a Local full name, a DECdns full name, and a fully qualified host name for DNS/BIND.

* Enter the full name for directory service LOCAL : LOCAL:.ELMER
* Enter the full name for directory service DECDNS : ACME:.WABBIT.ELMER
* Enter the fully qualified host name for DNS/BIND : ELMER.WABBIT.ACME.EDU

The node synonym is an alphanumeric character string between one and six characters long. The first character must be an alphabetic character; after the first character, the string can contain either alphabetic or numeric characters.

The node synonym is primarily a transition tool that allows you to use a Phase IV-style node name for your DECnet-Plus node. Other users can then find your node by using this synonym rather than your full name. If you are transitioning from DECnet Phase IV, consider using your Phase IV node name as your synonym. The synonym is required for Phase IV applications that can only handle Phase IV-style node names. If your network has only DECnet-Plus or OSI (Open Systems Interconnection) systems, you may not need a node synonym.

The default node synonym is the first six characters of the system’s last simple name. The last simple name is the string that follows the last period of your full name. For example, if you specify XYZ_CORP:.sales.east_coast.BrianMacKrill as a node full name, the default node synonym is BrianM.

If this system had previously been running DECnet Phase IV software, then you should use the old Phase IV node name as the synonym. If this system is joining a DECnet network for the first time, you can use any name for the synonym, as long as it meets the criteria listed above, and is unique within the network.

* What is the synonym name for this node? [ELMER] :

For information on node synonym directories, see Section B.2, “Node Synonym Directories”.

A naming cache is used to improve the performance of node name to address resolution. This naming cache supersedes the DECdns cache in older DECnet-Plus versions and is used when looking for addresses in the Domain and Local services, in addition to DECdns. Note that other applications that directly use DECdns will continue to use the DECdns cache instead of the naming cache.

The naming cache includes a mechanism to time out old entries. In this way, these entries are refreshed periodically to reflect the actual network environment.

BASIC

The BASIC option sets the naming cache timeout value to the default value of 30 days (30-00:00:00).

ADVANCED

The ADVANCED option prompts for the naming cache value:

* Naming cache timeout value? [30-00:00:00] :

To choose the default value of 30 days, press Return. Otherwise, enter any legal OpenVMS delta time value.

The session control address update interval is the time, in seconds, between updates of local tower address information.

BASIC

The BASIC option sets the session control address update interval to the default value of 10 seconds.

ADVANCED

The ADVANCED option prompts for the session control address update interval:

* Session Control Address Update Interval ? [10] :

To choose the default value of ten seconds, press Return. Otherwise, enter an interval value in seconds and press Return.

Periodically, DECnet-Plus saves a snapshot of the in-memory naming cache to disk. This allows systems, during startup, to have a naming cache that is already populated with entries, thereby preserving the contents of the naming cache across system reboots.

BASIC

The BASIC option sets the naming cache checkpoint interval to the default value of 8 hours.

ADVANCED

The ADVANCED option prompts for the naming cache checkpoint interval:

* Naming cache checkpoint interval? [08:00:00] :

To choose the default value of eight hours, press Return. Otherwise, enter any legal OpenVMS delta time value.

DECnet-Plus for OpenVMS allows an OpenVMS system to run integrated IS-IS, thus providing host-based routing functionality. Answer ROUTER if you want this system to support the host-based routing functionality. If you answer ROUTER, you must have the extended function license (see Section 1.6, “License Requirements”) for the host-based routing software to function. Answer ENDNODE if this system will depend on other nodes to provide routing.

* What type of node (Endnode or Router)? [ENDNODE] :

To configure an end node system, press Return. Otherwise, enter the node type.

This section only applies if you chose to configure your system as a router.

* Type of routing node (L1 or L2)? [L1] :

NET$CONFIGURE will assume that the MANUAL L1 ALGORITHM and
the MANUAL L2 ALGORITHM (if present) will be ROUTING VECTOR.

If LINK STATE is to be designated as the preferred routing
algorithm at either level, the DCL command file
SYS$MANAGER:ISIS$CONFIGURE.COM must be invoked AFTER this
procedure to correctly configure the NET$ROUTING_STARTUP.NCL.

* Maximum path splits [2] :

* PhaseIV Maximum Address [1023] :

* PhaseIV Maximum Area [63] :

If you want your system to communicate with Phase IV nodes, you must specify a Phase IV address and a Phase IV prefix. DECnet-Plus systems reference all network addresses (including Phase IV addresses) using the OSI Network Service Access Point (NSAP) address formats. The Phase IV address and a Phase IV prefix are used to construct a complete NSAP address.

A DECnet Phase IV-compatible address is a DECnet-Plus address, in the form area-number.node-number, that conforms to the Phase IV area and node limits; that is, the area number is from 1 to 63, and the node number is from 1 to 1023.

If there are no Phase IV systems on your network or you do not want to communicate with Phase IV systems, you do not need a Phase IV-compatible address. Entering a Phase IV address of 0.0 at configuration time indicates that this DECnet-Plus system does not have a Phase IV-compatible address, and will not communicate with Phase IV nodes.

* Enter PhaseIV Address [15.27] :

Enter the Phase IV address you want to use, or enter 0.0 if you do not want to communicate with Phase IV nodes.

BASIC

The BASIC option sets the Phase IV prefix to its default value of 49::. If you do not enter a Phase IV-compatible address, the BASIC option does not assign a Phase IV prefix value.

ADVANCED

If you entered a Phase IV-compatible address, the ADVANCED option prompts for the Phase IV prefix value:

* Enter Phase IV Prefix [49::] :

To choose the default value of 49::, press Return. Otherwise, enter a valid IDP value.

This section applies only if you chose to configure your system as an end node.

* Autoconfigure network addresses? [YES] :

%NET$CONFIGURE-I-PHASEIVNETINCL, the Phase IV N.E.T. will be included: phaseiv-net
* Enter Manual Network Entity Titles [ ]:

IDP and selector  = 41:45436192:local-area:node-id:00
43 decimal        = 2B hexadecimal (local area)
(43 * 1024) + 258 = 44290 decimal
44290 decimal     = AD02 hexadecimal
AD02 swapped      = 02AD hexadecimal (node ID)
The resulting NET is 41:45436192:00-2B:AA-00-04-00-02-AD:00

* DNA Address Format [TRUE] :

* Do you want to use segregated mode routing? [NO] :

The default ES Hello timer value determines the interval, in seconds, that the end system (ES) uses when sending out its Hello messages. This interval multiplied by 3 is the amount of time the other end of a routing adjacency waits before determining that this system is no longer able to accept connections.

BASIC

The BASIC option sets the ES Hello timer value to 600.

ADVANCED

The ADVANCED option prompts you for the ES Hello timer setting:

* Routing Default ES Hello Timer? [600] :

To select the default of 600, press Return. Otherwise, choose your own value and press Return.

The routing ES Cache Size attribute specifies the maximum number of entries in the ES cache.

BASIC

The BASIC option sets the ES cache size value to 512.

ADVANCED

The ADVANCED option prompts you for the ES cache size setting:

* Routing ES Cache Size? [512] :

To select the default of 512, press Return. Otherwise, choose your own value and press Return.

The net$configure procedure begins device configuration by checking to see if the Wide Area Network Device Drivers (WANDD) software has been installed but not configured. The WANDD software provides synchronous device support for DECnet-Plus.

If it finds the WANDD configuration file (sys$startup:wandd$configure.com), it displays a short message and asks if you want to add WANDD devices to your configuration:

You have installed wide area device support, but it has not been
configured. You may configure it now if you want.
* Do you want to configure Wide Area devices? [YES] :

To add WANDD devices to your configuration, press Return. To skip over the WANDD device configuration, enter NO and press Return.

If you select WANDD device configuration, the net$configure procedure invokes the WANDD configuration file, (sys$startup:wandd$configure.com). The next two sections describe the WANDD configuration dialog on OpenVMS I64 and OpenVMS Alpha systems and on OpenVMS VAX systems.

Configuring WANDD... [’?’ for HELP]

%WANDD$CONFIGURE-I-WANDDNOTCONFIG, WANDD has not been configured.
Configure WANDD? [YES]

    All installed autoconfigurable synchronous device drivers
    will be configured. However, the built-in serial port will
    only be configured if you answer "YES" to the next question.

Configure built-in serial port as synchronous? [YES]
Are you satisfied with your answers? [YES]

    This is the Configuration Procedure for the
    ===========================================
    VAX Wan Device Drivers for DECnet-Plus for VMS
    =============================================
  The Wide Area Network Datalinks and Drivers are a prerequisite
  for DECnet-Plus. They also provide synchronous datalinks in
  systems that do not use DECnet-Plus for networking.

  Access to DECnet-Plus datalinks (created by NCL) is possible via
  the QIO interface to the WAN pseudo-driver, WANDRIVER. Layered
  products that use synchronous devices do not normally require
  programming access to WANDRIVER. For further information, see
  the "DECnet/OSI for VMS WANDD Programming" guide.

Do you wish to use WANDRIVER [N] ?
Will you use DEC HDLC [Y] ?
Will you use LAPB/E (VAX P.S.I. requires LAPB/E) [Y] ?

  The DSV11 (Q-bus), DIV32 (Q-bus), DSB32 (BI-bus), DSF32 (MI-bus) and
  DSW devices are soft-loadable. The WANDD startup procedure will load
  the microcode for these devices if required.

Do you have any soft-loadable microcode devices on this system [N] ?
Will you use the VAXft DSF32 device driver [N] ? Y

  The VAXft DSF32 software supports the pairing of physical
  controllers to provide a fault-tolerant configuration. Such a
  pairing is called a Failover Set. The DSF32 device does not
  automatically create the failover sets, so you will need to pair
  controllers using the Failover Set Manager software.

  This management software can be invoked during system startup
  from within the command procedure WANDD$STARTUP_SF.COM, which is
  placed in the SYS$STARTUP directory by the kit installation
  procedure. If you want to have these Failover Sets automatically
  configured when the system starts up you will need to modify
  WANDD$STARTUP_SF.COM to include Failover Set Manager commands
  that you require.

Are you satisfied with the answers you have given [Y] ?
  If you have already started up the WAN Drivers and Datalinks
  (that is, if you have already successfully run
  SYS$STARTUP:WANDD$STARTUP.COM since your system was last
  booted), then you will need to reboot your system for your new
  configuration to take effect.

After adding the WANDD devices, the net$configure procedure does a complete system device scan:

%NET$CONFIGURE-I-SCANCONFIG, scanning device configuration - please wait

If no devices are found, the procedure displays a message and asks if you want to perform an autoconfigure operation to create a new set of available devices:

%NET$CONFIGURE-W-NODEVICES, no devices found
Should devices be autoconfigured? [YES] :

If you want to have the procedure autoconfigure devices, press Return. If you enter NO, the configuration procedure continues without autoconfiguring devices. However, if you do not autoconfigure devices, no devices will be available. On OpenVMS I64 and OpenVMS Alpha systems, the autoconfiguration is done using the command mcr sysman io auto. On OpenVMS VAX systems, the autoconfiguration is done using the command mcr sysgen autoconfigure all.

Normally, the OpenVMS system controls lines connected to terminal ports, as in interactive logins. You can, however, switch the line so that the DECnet-Plus software can use the line for an asynchronous data link to another system. Asynchronous data links are implemented in software and can be run over any directly connected terminal line that the OpenVMS system supports.

The asynchronous protocol provides for a full-duplex data link and can be used for remote asynchronous communications over a telephone line using a modem. Asynchronous data links are not supported for maintenance operations or for controller loopback testing.

BASIC

The BASIC option does not offer the choice of configuring asynchronous devices. Proceed to Section 6.6.4, “Configuring Data Links and Routing Circuits”.

ADVANCED

The ADVANCED option asks whether you want to configure asynchronous data links:

* Do you want asynchronous datalink support? [YES] :

Answer NO if you do not want to configure any asynchronous data links. Proceed to Section 6.6.4, “Configuring Data Links and Routing Circuits”.

If you answer YES, the procedure verifies that the asynchronous device driver (sys$ldr:asydriver.exe) is available. If the file is not found, the procedure displays a warning that you must install the WANDD software:

****************************************************************
                            WARNING
The WANDD software is not installed on the system. If you want
asynchronous datalink support, make sure that the WANDD software
is installed and configured on your system.
****************************************************************

The procedure allows you to continue. However, you must install the WANDD software or the data links you configure will be unusable.

* Do you want to configure static lines? [YES]:

* Terminal device name (ex: TXA0,TXA2,...)? []:

Do you want to configure dynamic lines? [YES]:

* Do you want to configure explicit dynamic lines? [YES]:

* Do you want to configure floating dynamic lines? [YES]:

* Do you want to configure any more asynch lines? [NO]:

* Line speed for device-name? [2400]:
* Will this line require full modem control [YES]:

* Number of floating speed bps control modem ctrl lines? [1]:

* Do you want to configure any more floating lines? [YES]:

* Do you want to configure any more asynch lines? [NO]:

You now need to supply names for the data links and routing circuits you have on your system.

For HDLC and synchronous links, you also need to select which protocol should be used on the link (HDLC, DDCMP, or NONE).

BASIC

The BASIC option automatically configures all available network devices. It uses the default naming conventions for all data links and routing circuits. It also uses built-in defaults for the protocol on all HDLC and synchronous links.

ADVANCED

The ADVANCED option prompts you for the simple name that you want to use for each data link and routing circuit. For HDLC and synchronous lines, the procedure precedes the link and routing circuit name questions with a question about which protocol should be used on the link (HDLC, DDCMP, or NONE):

* Data Link protocol for ZR-0-0 (SSCC)            [HDLC] :
* Data Link name to use for ZR-0-0 (SSCC)?      [HDLC-0] :
* Routing Circuit Name for Data Link ’HDLC-0’?  [HDLC-0] :

The ‘‘Data Link name’’ question can take on several slightly different forms depending on the device being configured.

You have the option of enabling FDDI large packet support on this
routing circuit. Note that a Phase V router on the LAN (preferably
on the FDDI) is required in order to use FDDI large packet support.
* Use large packets on Routing Circuit FDDI-0? [YES] :

* Level 1 Cost for Routing Circuit ’CSMACD-0’?             [8] :
* Level 1 Router Priority for Routing Circuit ’CSMACD-0’? [64] :
* Level 2 Cost for Routing Circuit ’CSMACD-0’?             [8] :
* Level 2 Router Priority for Routing Circuit ’CSMACD-0’? [64] :

NET$CONFIGURE has determined that you have multiple broadcast circuits.
Your system has been configured to enable Phase IV addressing on only
one of those circuits. When Phase IV addressing is enabled, the
datalink MAC address is set according to Phase IV addressing rules
(i.e. AA-00-04-00-nn-nn).

It is undesirable (and invalid) for more than one circuit using
Phase IV addressing to be connected to the same LAN. However, if
your circuits are on distinct and separate LANs, and the Phase IV
style MAC address is desired on more circuits, you may edit the
SYS$MANAGER:NET$ROUTING_STARTUP.NCL script prior to starting your
network. For example, you would change the following command:

SET NODE 0 ROUTING CIRCUIT SVA-1 ENABLE PHASEIV ADDRESS = FALSE

to this in order to enable Phase IV addressing on the circuit:

SET NODE 0 ROUTING CIRCUIT SVA-1 ENABLE PHASEIV ADDRESS = TRUE

* Enable Phase-IV Addressing on Routing Circuit ’CSMACD-0’? [YES] :

If you have configured X.25 for OpenVMS on an I64 or OpenVMS Alpha system or the X.25 functionality provided by DECnet-Plus on an OpenVMS VAX system (formerly known as VAX P.S.I.), the configuration procedure now gives you the option of configuring DECnet-Plus to use any previously configured X.25 data links.

BASIC

The BASIC option configures the NSP transport using the default values discussed in this section. Proceed to Section 6.7.2, “Specifying the OSI Transport Configuration”.

ADVANCED

The ADVANCED option begins the NSP transport configuration with following question:

* Configure the NSP Transport? [YES] :

Answer YES if you want the system to communicate with DECnet Phase IV nodes If you answer NO, the procedure still loads the NSP transport image. However, NSP transport is not configured or usable until you run the net$configure procedure and answer YES to the preceding question.

%NET$CONFIGURE-I-NSPCONFIG, NSP will be configured since a Phase
IV address is being used

The procedure then displays a series of prompts for three interrelated settings of the NSP transport configuration:

* Maximum number of logical links?     [200] :
* Maximum transmit and receive window? [20] :
* Maximum receive buffers?             [4000] :

The first question determines the maximum number of active transport connections (logical links) allowed at any one time to the NSP transport. Press Return to select the default value or enter a number from 1 to 65535.

The second question determines the value of the transport’s maximum window attribute. VSI recommends setting a value of 20 for the maximum transmit and receive window option. Press Return to select the default value or enter a number from 1 to 65535.

The third question prompts for the number of receive buffers to preallocate. In a typical network environment, VSI recommends setting a value for maximum receive buffers that is no more than the value you entered for the maximum window option multiplied by the value you specified for the maximum number of logical links.

For additional information about these parameters, see the VSI DECnet-Plus for OpenVMS Network Management Guide.

* NSP flow control policy (SEGMENT, NO)? [SEGMENT] :

BASIC

The BASIC option configures the OSI transport using the default values discussed in this section (including enabling OSI applications over TCP/IP and DECnet over TCP/IP). Proceed to Section 6.7.3, “Specifying Transport Congestion Avoidance”.

ADVANCED

The ADVANCED option begins the OSI transport configuration with following question:

* Configure the OSI Transport or run over TCP/IP? [YES] :

Answer YES if you want the system to communicate with DECnet-Plus nodes, OSI nodes of other vendors, or if you plan to install the OSAK, FTAM, or VT software. Also answer YES if you want to use DECnet over TCP/IP or OSI applications over TCP/IP. If you answer NO, the procedure still loads the OSI transport images. However, OSI transport is not configured or usable until you run the net$configure procedure and answer YES to the preceding question.

The procedure then displays a series of prompts for three interrelated settings of the OSI transport configuration:

* Maximum number of logical links? [200] :
* Maximum transmit and receive window? [20] :
* Maximum receive buffers? [4000] :

The first question determines the maximum number of active transport connections (logical links) allowed at any one time to the OSI transport. Press Return to select the default value or enter a number from 1 to 65535.

The second question determines the value of the transport’s maximum window attribute. VSI recommends setting a value of 20 for the maximum transmit and receive window option. Press Return to select the default value or enter a number from 1 to 65535.

The third question prompts for the number of receive buffers to preallocate. In a typical network environment, VSI recommends setting a value for maximum receive buffers that is no more than the value you entered for the maximum window option multiplied by the value you specified for the maximum number of logical links.

For additional information about these parameters, see the VSI DECnet-Plus for OpenVMS Network Management Guide.

* Run OSI Applications over TCP/IP? [YES] :

* Run DECnet over TCP/IP? [YES] :

* Interface(s) for DECnet/OSI over TCP/IP ? [ALL] :

NET$CONFIGURE-W-NODOMAIN, DECnet over IP requires DOMAIN in the directory services list

NET$CONFIGURE-W-NOPWIP, DECnet over IP requires the PWIP driver to be enabled

One feature of both transports is the ability to use the Congestion Experienced field in the Connectionless-mode Network Service (CLNS) routing header, and to implement a Congestion Avoidance scheme in heavily congested networks. The CLNS Congestion Experienced field is used by routers that support this feature (such as DECNIS) to give an early indication of congestion. When the transport receives data that passed through a network path where the Congestion Experienced bit is set, the transport reduces the transmit rate of the sending end system to help alleviate network congestion.

This feature works well in networks where all protocols support Congestion Avoidance mechanisms. However, it has been noted that in some heavily congested multi-protocol networks, this feature can negatively impact the performance of DECnet compared to other protocols.

VSI recognizes that most of its customers have multi-protocol networks. In this environment, not all network protocols have Congestion Avoidance mechanisms. Therefore, the default for this option is to disable Congestion Avoidance.

If you operate in an environment where you can take advantage of Congestion Avoidance mechanisms, VSI recommends that you enable the feature.

BASIC

The BASIC option configures each transport with congestion avoidance disabled.

ADVANCED

The ADVANCED option asks the following question about your network environment:

* Is this system operating in a multi-protocol network? [YES] :

If you take the default answer of YES, then both transport’s Congestion Avoidance characteristics are set to FALSE and this option is disabled. Answer NO to this question to set the characteristics to TRUE and enable the option.

NSP connections over slow-speed point-to-point lines require adjustments to NSP’s delay factor and maximum window settings. The configuration utility asks the following question if you have configured point-to-point devices that have the potential to operate at very slow line speeds:

* Are the point-to-point lines utilizing line speeds less than 9600 BPS? [NO] :

Answer YES if you have slow-speed point-to-point device. Otherwise, press Return to accept the default answer.

If the OSI transport is configured, a test program (sys$test:osit$ivp) is installed. You can use this program to verify OSI transport operation. For more information about the OSI test program, see the VSI DECnet-Plus for OpenVMS Network Management Guide.

BASIC

The BASIC option selects the user name SYSTEST for the test account.

ADVANCED

The ADVANCED option asks for the user name to use when running the OSI test program:

* Username for OSI loopback test application to use? [SYSTEST] :

Press Return to accept the default user name for the application loopback test account or enter a user name.

If you configured the OSI transport, net$configure automatically creates the default OSI templates required by the OSAK and FTAM installation verification procedures (IVPs). The procedure displays a message stating that these default OSI templates have been created:

%NET$CONFIGURE-I-CREDEFOSITEMPLATE, created default OSI templates

The default templates created are osit$loop_clns, osit$loop_cons, osit$rfc1006, and, if DECnet over TCP/IP was chosen, osit$rfc1006plus.

In addition, a template with the name DEFAULT is created when the OSI transport entity is enabled. This template is used when no template is specified.

BASIC

The BASIC option does not provide the opportunity to create additional OSI templates. You will not be able to use OSI applications to make connections to other OSI systems unless you use the ADVANCED option to create additional OSI templates. You can do this at a later time. Proceed to Section 6.8, “Configuring Time Zone Differential Factors”.

ADVANCED

The ADVANCED option provides the opportunity to create additional OSI templates. The dialog begins by asking if you want to create additional templates:

* Do you want to create additional OSI templates? [NO] : yes

If you answer YES, the procedure uses the prompts discussed in this section to obtain the information required to configure the OSI templates. If you answer NO, you can create additional templates at a later time. Proceed to Section 6.8, “Configuring Time Zone Differential Factors”.

* Use full CLNP or Null Internet? [Full CLNP] :

%NET$CONFIGURE-E-ERRINRTGCIRC, error in accessing a default routing circuit name

* Which routing circuit is this Null Internet template for? [CSMACD-0] :

%NET$CONFIGURE-E-RTGCIRCNOTFND, routing circuit name circuit-name not found in the routing circuit list

* Which CLNS Inactive Area to use? [49::FF-00] :

* CONS template name? [OSI Transport] :

* CONS filter name? [OSI Transport] :

* Local RFC1006 port number? [102] :

* RFC1006 listener port number? [102] :

The procedure begins the customization of the event dispatcher by asking if you want to configure any event sinks. Event sinks manage incoming event connections and maintain a set of filters (global, specific, and catch-all) that are applied to all data streams assigned to the sink.

Indicate if you want to configure a custom sink:

* Configure a Sink? [YES] :

If you want to create a customized sink, answer YES (for example, if you want to change where to send the output: a terminal, a printer, or a file). If you do not want to configure a customized sink, answer NO and proceed to Section 6.9.2, “Outbound Streams”.

The sink’s configuration is now complete.

Next, the procedure asks if you want to create another sink:

* Configure another Sink? [NO] :

If you do not want to configure another sink, press Return to proceed to Section 6.9.2, “Outbound Streams”. If want to configure another sink, enter YES and press Return. The procedure returns you to the ‘‘Sink name?’’ prompt discussed in Step 1 and repeats the prompts required to configure another sink.

The procedure continues the customization of the event dispatcher by asking if you want to configure any outbound streams. Outbound streams represent an outgoing connection to an event sink. An outbound stream manages the connection to the sink and it filters, processes, and transmits events to the sink.

Indicate if you want to configure a custom outbound stream:

* Configure an Outbound Stream? [YES] :

If you want to create a customized outbound stream, answer YES (for example, if you want to change where to send the event data stream). If you do not want to create a customized outbound stream, answer NO and proceed to Section 6.9.3, “Phase IV Relay”.

The outbound stream’s configuration is now complete.

Next, the procedure asks if you want to create another outbound stream:

* Configure another Outbound Stream? [NO] :

If you do not want to configure another outbound stream, press Return to proceed to the Phase IV Relay section. If you want to configure another outbound stream, enter YES and press Return. The procedure returns you to the ‘‘Outbound Stream name?’’ prompt discussed in Step 1 and repeats the prompts required to configure another outbound stream.

A Phase IV relay allows you to record and process events that occur on an OpenVMS system running DECnet Phase IV software. The Phase IV Relay entity receives the events from a Phase IV node, encapsulates them, and posts them in the DECnet-Plus system Event Dispatcher.

Indicate if you want to include a Phase IV relay:

* Configure Phase IV Relay? [YES] :

Answer YES to create the Phase IV Relay.

When configuring a local system (versus a satellite system), all configuration changes made by using option 2 are executed directly. For this reason, the network must be running. During namespace selection processing, net$configure always begins by verifying that the network is running. If the network is not running, the procedure asks you if you want to start the network:

* Do you want to start the network ? [YES]:

Answer YES to start the network and continue the node’s configuration. If you answer NO, or if the procedure fails in it’s attempt to start the network, the procedure warns you that you must elect to start the network or correct the problem that is causing the start attempt to fail and then reinvoke option 2:

%NET$CONFIGURE-E-NETNOTSTARTED, network not started
%NET$CONFIGURE-DNSNOTCONFIG, DNS could not be configured
 **********************************************************************
 NET$CONFIGURE.COM cannot complete your system’s network configuration.
 As a result, your system may be left in an inconsistent state if you
 try to startup the network manually or if you decide to reboot your
 system.
 When the problem is rectified and you are ready to start the network,
 please invoke the NET$CONFIGURE.COM procedure and choose menu option 2
 (Change naming information) so that the configuration procedure can
 finish your system’s network configuration before starting the network.
 **********************************************************************

After displaying this warning, the procedure aborts the transaction and returns to the main options menu:

%NET$CONFIGURE-I-LASTTRANSABORT, last transaction aborted
     Configuration Options for Node ASHFLD
    [0] Exit this procedure
    [1] Perform an entire configuration
    [2] Change naming information
.
.
.
* Which configuration option to perform? [0] :

During satellite node configurations (see Section 7.15, “Configuring Satellite Nodes”), the procedure does only configuration dialog processing. Rather than actually manipulate the namespace, the procedure generates a node rename file (net$startup_rename.com) in the satellite’s sys$manager: directory. To apply the node name change, you must reboot the satellite node. During startup, the net$startup.com procedure searches for the node rename file and executes the file if located.

This section describes how to add the DECdns namespace as the primary namespace to a system formerly configured exclusively in the Local namespace.

Configuration Dialog Processing

The following example shows a typical dialog to change the node from a Local namespace-only node to a node using both the DECdns and Local namespaces (with DECdns as the primary name service):

* Which configuration option to perform?                [1] : 2
* Enter the directory services to use on the system [LOCAL] : decdns,local
* Enter the full name for directory service          DECDNS : VSI:.ashfld
* Enter the full name for directory service LOCAL [LOCAL:.ASHFLD] :
* What is the synonym name for this node?          [ASHFLD] :
* Naming cache timeout value?                 [30-00:00:00] :
* Session Control Address Update Interval ?            [10] :
* Naming cache checkpoint interval?              [08:00:00] :

Namespace Selection Processing

Based on the answer provided during configuration dialog processing, the configuration procedure verifies that it can communicate with the server containing the DECdns directory and then calls the dns$configure.com procedure to configure the clerk for this namespace:

sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
Your default namespace nickname is VSI.
Your default namespace NSCTS is AA-00-04-00-DE-11-A0-AA-F9-6F-56-DE-8E-00.

If the configuration procedure cannot communicate with the DECdns server containing the DECdns directory, the procedure displays the following message:

%NET$CONFIGURE-E-DNSNOSHOW, unable to show directory directory

Namespace Configuration Processing

Based on the answers provided during configuration dialog processing, the configuration procedure executes the new name service searchpath NCL script, renames the node, modifies the Local namespace entry, registers the node in the DECdns namespace, flushes the CDI cache, updates the node’s address towers, and updates the backtranslation softlink for the node:

%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to VSI:.ASHFLD

Directory Service: Local name file

Modifying the node: LOCAL:.ASHFLD
Modifying the node towers

Finished obtaining address tower information
%NET$CONFIGURE-I-IMPORTFILECREATED, created the DECNET_REGISTER import file

Directory Service: DECdns

Updating nodes listed in SYS$MANAGER:DECNET_REGISTER_IMPORT_FILE_ASHFLD.TXT
   1) VSI:.ASHFLD

Number of nodes registered: 1
Number of nodes modified: 0

%NET$CONFIGURE-I-REGSUCCESS, node has been successfully registered in the DECdns directory service
%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries
%NET$CONFIGURE-I-CHECKPOINTWAIT, waiting for CDI to write the node name to the CDI cache file
%NET$CONFIGURE-I-CHECKPOINTDONE, the node name has been written to SYS$SYSTEM:DECNET$CDI_CACHE.DAT
%NET$CONFIGURE-I-TOWERSUPDATED, updated address towers for node
%NET$CONFIGURE-E-BCKTRNUPDATED, updated backtranslation softlink for node

The procedure then displays the configuration summary, recalculates the NCL script file checksums, and redisplays the main options menu:

   Summary of Configuration
Node Information:
   Directory Services Chosen:               DECDNS,LOCAL
   Primary Directory Service:               DECDNS
   DECdns Full name:                        VSI:.ASHFLD
   Local Full name:                         LOCAL:.ASHFLD
   Node Synonym:                            ASHFLD
   Phase IV Address:                        24.66
   Phase IV Prefix:                         49::
   DECdns Node Type:                        Clerk
   Session Control Address Update Interval: 10
   Routing Node Type:                       ENDNODE
   Autoconfiguration of Network Addresses:  Enabled
   Routing ESHello Timer:                   600
   Routing ES Cache Size:                   512
.
.
.
%NET$CONFIGURE-I-MODCHECKSUM, checksumming NCL management scripts modified by NET$CONFIGURE
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration complete

   Configuration Options for Node ASHFLD
   [0] Exit this procedure
   [1] Perform an entire configuration
   [2] Change naming information
.
.
.
* Which configuration option to perform? [0] :

This section discusses the same task as the previous section (adding a DECdns namespace name to a system formerly configured exclusively in the Local namespace). However, it shows the extra processing that occurs when you join a namespace that is not available on your node’s LAN.

Configuration Dialog Processing

For the purposes of this discussion, the configuration dialog processing is assumed to be identical to the processing shown in Section 7.6.3, “Changing a Node to Use DECdns as the Primary Namespace”.

Namespace Selection Processing

If your node is a DECdns clerk and the net$configure procedure detects that the namespace you identified in the system’s DECdns full name is not served by a DECdns server on the LAN, it displays a list of all the namespaces that do exist on the LAN:

The namespace you specified was VSI.
%DNS-E-NOMATNS, The specified namespace is not being served on your LAN.
         Please choose from the following list:
[ 1] APOLLO
[ 2] IAF
[ 3] MIDAS_NS
[ 0] - Reject this list -
  Pick a number from the list: 0

When you see this display, type 0 and press Return to reject the list of namespaces currently known on your LAN.

  Attempts to configure DECdns via a LAN have failed.
  Type Y to attempt a WAN connection to a remote DECdns
  server. To stop DECdns Configuration and return
  control to the NET$CONFIGURE utility, type N at the
  following prompt:
Do you want to connect to a remote DECdns server via a WAN [y]:

  Attempting to configure a clerk via a WAN connection.
  Enter the NSAP or Phase IV compatible address or IP address of the server
  you want to connect to: 24.16
  Getting server data, please wait...

If the procedure successfully connects with the server, the remainder of the namespace selection processing is identical to Section 7.6.3, “Changing a Node to Use DECdns as the Primary Namespace”.

If the procedure cannot connect to the remote server, the procedure displays the following messages, aborts the transaction, and displays the main options menu:

Could not get information from server. Both Phase IV and Phase V
connection attempts failed. Use the following information to help correct
the problem.

Could not connect to remote Phase V server
Could not connect to remote Phase IV server:

The WAN configuration attempt failed. Do you wish to retry? [y]: N

%DNS-E-NOCONFIG, DECdns clerk is not configured.
%NET$CONFIGURE-I-LASTTRANSABORT, last transaction aborted

Correct the problem preventing the connection to the WAN server and run net$configure again.

Namespace Configuration Processing

The namespace configuration processing is identical to the namespace configuration processing shown in Section 7.6.3, “Changing a Node to Use DECdns as the Primary Namespace”. When performing the actual namespace configuration processing, it makes no difference whether the DECdns server is on a LAN or on a WAN.

This section describes how to convert a DECdns clerk system into a DECdns server system.

Configuration Dialog Processing

To convert a DECdns clerk system to a DECdns server, you must install the DECdns server component using the PCSI installation procedure (see Chapter 3, Installing DECnet-Plus for OpenVMS). You can install the DECdns server before or after the initial network configuration.

Whether you installed the DECdns server software before or after the initial configuration, if you elect to create a new DECdns server system, the procedure warns you that you must specify DECdns as the primary name service when you configure a DECdns server for the first time:

Your node will be configured as a DNS Server. Since you are
configuring this DNS server for the first time, you must specify
DECdns as the primary naming service.

If you did not enter DECdns as the primary name service, the procedure displays the following warning and gives you a chance to re-enter the name service list with DECdns as the primary name service:

  You must specify DECdns as the primary naming service while
  configuring a DECdns server for the first time. If you answer NO
  to the next question, then NET$CONFIGURE will rename the SYS$STARTUP:
  DNS$SERVER_STARTUP.COM file to .COM-DISABLED so that the node will
  not boot as a DNS server until it has been configured properly.

* Do you want to re-enter your list of directory services? [YES]:

If you specify DECdns as the primary naming service, configuration dialog processing continues as shown in the configuration dialog processing section of Section 7.6.3, “Changing a Node to Use DECdns as the Primary Namespace”.

If you do not re-enter the list of directory services with DECdns as the first name service, the procedure renames the DECdns server startup file back to .com-disabled and the conversion to a DECdns server is aborted.

If you do not have a proper license for the DECdns server software (DVNETEXT for OpenVMS I64 and OpenVMS Alpha systems or DVNETRTG for OpenVMS VAX systems), the procedure displays a message explaining that you need a license, renames the dns$server_startup.com file to dns$server_startup.com-disabled, and reprompts you for a list of directory services:

  OpenVMS I64 and OpenVMS Alpha DECdns servers require the DVNETEXT
  license. This license is not yet loaded so this system will be
  configured as a DECdns clerk. To reconfigure this system as a server,
  please load this license and run NET$CONFIGURE again choosing Option 2.

%RENAME-I-RENAMED, SYS$SYSROOT:[SYS$STARTUP]DNS$SERVER_STARTUP.COM;1 renamed to SYS$SYSROOT:[SYS$STARTUP]DNS$SERVER_STARTUP.COM-DISABLED;1

* Enter the directory services to use on the system [LOCAL] :

* Enter the full name for directory service DECDNS : VSI:.ASHFLD

Namespace Selection Processing

To configure a new namespace, the net$configure procedure calls dns$configure.com twice: first to configure the system with the Local namespace as primary (this is a requirement for namespace creation), then to configure the system with the new namespace as primary:

sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
Your default namespace nickname is LOCAL.
Your default namespace NSCTS is 08-00-2B-0D-C0-9D-5F-FA-A9-88-43-46-95-00.
The namespace you specified was VSI.

When dns$configure.com is called with the new namespace, it indicates that the namespace is not currently being served on the LAN, displays a list of all the known namespaces, and asks you to choose a known namespace or reject the list entirely:

%DNS-E-NOMATNS, The specified namespace is not being served on your LAN. please choose from the following list
[ 1] AUTUMN
[ 2] DEC
[ 3] DOMAIN
[ 0] - Reject this list -
Pick a number from the list: 0

When you see this display, enter 0 and press Return to reject the list of known namespaces. The procedure then asks if you want to create a new namespace:

  If you are installing DECnet-Plus for OpenVMS for the first time
  and you want to create a namespace, type Y. If you want to
  attempt a WAN connection to a remote DECdns server,
  type N (default) at the following prompt:

* Do you want to proceed with creating a new namespace [n]: y

If you answer NO, the dns$configure.com procedure returns an error to the net$configure procedure. The transaction is aborted and the main options menu is redisplayed.

If you answer YES, the dns$configure.com procedure asks you for the clearinghouse name to use for the new namespace, starts the DECdns server process, and informs you that the default namespace has been set to the new namespace:

   Your next input will determine the name of the clearinghouse
   in your namespace VSI. Enter the clearinghouse name as
   alphanumeric and/or underscore characters.
Enter a simple name for the clearinghouse: VSI_CH
Node 0
at 2003-03-28-17:40:35.901-04:00I675.395
Creating DECdns Server process ...
%RUN-S-PROC_ID, identification of created process is 00000082
Your default namespace nickname is VSI.
Node 0
at 2003-03-28-17:40:46.777-04:00I675.396

Namespace Configuration Processing

During namespace selection processing, the dns$configure.com procedure only creates the new namespace. The net$configure procedure now populates the namespace with the initial groups and directories required of all namespaces (see the VSI DECnet-Plus Planning Guide for more information about how DECnet-Plus uses the DECdns namespace):

%NET$CONFIGURE-I-NEWNAMESPACE, a new namespace has been created

%NET$CONFIGURE-I-ADDGROUP, adding .WorldRead_Group to the new namespace

Create the initial namespace directories.
Press Ctrl/Z at any question to cancel the initialization.

* Phase IV prefix value [afi:idi:predsp, Def=49::]:
* Maximum Phase IV area to use [1-63, Def=63]:

The DECdns namespace groups and directories will now be created. This might
take up to 67 minutes or more, depending on the speed of the DECdns
server system and the amount of traffic on the network.
Creating the VSI:.DNA_Registrar group.
Creating the VSI:.DNA_BackTranslation directory.
Creating the VSI:.DNA_BackTranslation.%X49 directory.
Creating the VSI:.DNA_BackTranslation.%X49.%X0001 directory.
Creating the VSI:.DNA_BackTranslation.%X49.%X0002 directory.
.
.
.
Creating the VSI:.DNA_NodeSynonym directory.
Creating the VSI:.DTSS_GlobalTimeServers directory.

DECdns namespace initialization for DECnet use is complete.

The procedure then gives you a summary of further actions you must take to make the namespace fully functional and displays a summary of the directories it created (and any errors encountered during their creation):

If this is the first time you have initialized the namespace for DECnet
use, use SYS$SYSTEM:DECNET_REGISTER.EXE to:

* Press Return to continue

- Create a command file to automatically register previously defined
  Phase IV nodes. Execute this command file before you manually
  register any other nodes using SYS$SYSTEM:DECNET_REGISTER.EXE.

- Create any directories you need for node names that should be registered
  immediately, according to your namespace design. This includes the node
  you are currently running on.

- Be sure to add backtranslation directories for any non Phase IV areas/IPDs.
  Failure to do so will lead to Backtranslation Failures. Once you’ve added
  the necessary backtranslation directories, you may need to use the
  ncl flush session control naming cache entry "*" command.

- Change the local node’s registered name from its default name to its
  final full name. The local node will be registered as a Phase IV node
  with a default name when you execute the Phase IV node registration
  command file above.

- Change the currently registered names of other nodes from their default
  names to their final full names when appropriate (for example, when they
  are upgraded to run DECnet-Plus software).
  Continue to use SYS$SYSTEM:DECNET_REGISTER.EXE to:

- Create any additional directories you need for node names, as new nodes
  are brought up on the network.

- Register new nodes as they are brought up on the network.

- Add members to the VSI:.DNA_Registrar access control group.

* Press Return to continue

Additionally, you can use the DECdns control utility to:

- Add specific access control to individual directories, objects, and
  soft links.

- Create replicas of directories.

The following were created:

  Group:       VSI:.DNA_Registrar
  Directory:   VSI:.DNA_BackTranslation
  Directory:   VSI:.DNA_BackTranslation.%X49
  Directories: VSI:.DNA_BackTranslation.%X49.*
  Directory:   VSI:.DNA_NodeSynonym
  Directory:   VSI:.DTSS_GlobalTimeServers

* Press Return to continue
%NET$CONFIGURE-I-CREATEINITDIR, created initial namespace directories

Now that the new namespace is properly configured for DECnet-Plus use, the procedure registers your system in the new namespace using the information you supplied during configuration dialog processing:

Directory Service: DECdns
Registering the node: VSI:.ASHFLD
%NET$CONFIGURE-I-REGSUCCESS, node has been successfully registered in the VSI: directory service

Based on the answers provided during configuration dialog processing, the configuration procedure executes the new name service searchpath NCL script, renames the node, modifies the Local namespace entry, flushes the CDI cache, updates the node’s address towers, and updates the backtranslation softlink for the node:

%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to
  VSI:.ASHFLD

Directory Service: Local name file

Modifying the node: LOCAL:.ASHFLD
Modifying the node towers

%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries
%NET$CONFIGURE-I-TOWERSUPDATED, updated address towers for node
%NET$CONFIGURE-I-BCKTRNUPDATED, updated backtranslation softlink for node

The procedure then displays the configuration summary, recalculates the NCL script file checksums, and redisplays the main options menu:

   Summary of Configuration
Node Information:
   Node Type:                 ENDNODE
   Directory Services Chosen: DECDNS
   Primary Directory Service: DECDNS
   DECdns Full name:          VSI:.ASHFLD
   DECdns Node Type:          Server
   Node Synonym:              ASHFLD
   Phase IV Address:          24.121
   Phase IV Prefix:           49::
   Autoconfiguration of Network Addresses:  Enabled
   Session Control Address Update Interval: 10
   Routing ESHello Timer:     600
   Routing ES Cache Size:     512

.
.
.
%NET$CONFIGURE-I-MODCHECKSUM, checksumming NCL management scripts modified by NET$CONFIGURE
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration completed

   Configuration Options for Node ASHFLD
   [0] Exit this procedure
   [1] Perform an entire configuration
   [2] Change naming information

$ net_register = "$sys$system:decnet_register"
$ net_register register node VSI:.ASHFLD directory DECDNS -
_$ towers {SC3/NSP/phaseiv-address,SC3/TP4/phaseiv-address} SYNONYM ASHFLD

This section describes how to convert a DECdns server system to a DECdns clerk system.

Configuration Dialog Processing

The procedure checks for the existence of a valid DECdns server configuration (by searching for the sys$manager:dns_files.txt file). If it finds the file and the file passes verification testing, the procedure displays the following message and asks if you want to convert the server to a clerk:

  The directory pointed to by SYS$MANAGER:DNS_FILES.TXT is valid.
  This indicates that the node has been previously configured as
  a DECdns server.

  Answer YES to the next question if you would like to rename the
  the DNS$SERVER_STARTUP.COM file to .COM-DISABLED to change this
  node to a DECdns clerk. If you take the default, the node will
  be configured as a DECdns server.

* Do you want to rename DNS$SERVER_STARTUP.COM to .COM-DISABLED.COM? [NO]:

Answer NO to leave your system configured as a DECdns server system. Answer YES to rename the sys$startup:dns$server_startup.com file to sys$startup:dns$server_startup.com-disabled and configure your system as a DECdns clerk. In both cases, configuration dialog processing continues as shown in the configuration dialog processing section of Section 7.6.3, “Changing a Node to Use DECdns as the Primary Namespace”.

Namespace Selection Processing

Assuming that no other changes are made during configuration dialog processing, namespace selection processing verifies that it can communicate with another DECdns server containing the same namespace and then calls the dns$configure procedure to reconfigure the clerk for the namespace:

sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
Your default namespace nickname is VSI.
Your default namespace NSCTS is AA-00-04-00-DE-11-A0-AA-F9-6F-56-DE-8E-00.

Namespace Configuration Processing

The procedure reruns the name service searchpath NCL script. Whenever a DECdns namespace is involved the process renames the node, flushes the cache, updates the address towers, and updates the backtranslation softlink:

%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to VSI:.ASHFLD
%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries
%NET$CONFIGURE-I-TOWERSUPDATED, updated address towers for node
%NET$CONFIGURE-I-BCKTRNUPDATED, updated backtranslation softlink for node

The procedure then displays the configuration summary, recalculates the NCL script file checksums, and redisplays the main options menu:

   Summary of Configuration
Node Information:
   Node Type:                 ENDNODE
   Directory Services Chosen: DECDNS
   Primary Directory Service: DECDNS
   DECdns Full name:          VSI:.ASHFLD
   DECdns Node Type:          Clerk
   Node Synonym:              ASHFLD
   Phase IV Address:          24.121
   Phase IV Prefix:           49::
   Autoconfiguration of Network Addresses: Enabled
   Session Control Address Update Interval: 10
   Routing ESHello Timer:     600
   Routing ES Cache Size:     512

.
.
.
%NET$CONFIGURE-I-MODCHECKSUM, checksumming NCL management scripts modified by NET$CONFIGURE
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration completed

   Configuration Options for Node ASHFLD
   [0] Exit this procedure
   [1] Perform an entire configuration
   [2] Change naming information

This section describes how to revert back to a previous DECdns server configuration after converting a DECdns server system to a DECdns clerk system.

Configuration Dialog Processing

When you previously converted the system to a DECdns clerk system, the net$configure procedure renamed the sys$startup:dns$server_startup.com file to dns$server_startup.com-disabled during the conversion. The procedure informs you that this was done and asks if you want to change the system back into a DECdns server:

   A SYS$STARTUP:DNS$SERVER_STARTUP.COM-DISABLED file has been located.
   This indicates that the DECdns server software has been installed,
   but this system was previously configured as a DECdns clerk.

   Answer YES to the next question if you want to rename this file
   to DNS$SERVER_STARTUP.COM and configure the node as a DNS Server.
   If you take the default, this node will remain a DNS Clerk.

* Do you want to change this system into a DECdns server? [NO]:

Answer NO to leave your system configured as a DECdns clerk system. Answer YES to rename the sys$startup:dns$server_startup.com-disabled file to sys$startup:dns$server_startup.com and reconfigure your system as a DECdns server.

If you choose to convert the system back to a DECdns server, the procedure checks for the existence of a valid DECdns server configuration (by searching for the sys$manager:dns_files.txt file). If it finds the file and the file passes verification testing, the procedure displays the following message:

The directory pointed to by SYS$MANAGER:DNS_FILES.TXT is valid.
This indicates that the node has been previously configured as a DECdns server.

If the procedure does not find the configuration file or the file does not pass verification testing, the procedure treats this configuration as a new conversion to a DECdns server. See the configuration dialog processing section in Section 7.6.5, “Converting a DECdns Clerk System to a DECdns Server System” for information about limitations on the directory service list in this case (see the information directly following the bulleted list).

Assuming that the configuration file is found and that it passes verification testing, the procedure begins the standard directory service/node name dialog by asking for the directory services to use and, based on the answer, the DECdns full name:

* Enter the directory services to use on the system [LOCAL] : decdns,local
* Enter the full name for directory service DECDNS          : VSI:.ashfld

Because you have specified a DECdns name on a system that already has a DECdns server configuration, the procedure checks the server’s clearinghouses to make sure that you are specifying a namespace already served by this system:

NET$CONFIGURE is searching for pre-existing clearinghouses on this DNS Server.

Clearinghouse: VSI:.VSI_CH

Note that this check requires that the net$configure procedure start the DECdns server using the newly renamed sys$startup:dns$server_startup.com file. If you are running net$configure on the console and you have events enabled, you should see one or more Clearinghouse Enabled events as the DECdns server enables the existing clearinghouses on the server.

The net$configure procedure does not support creation of more than one namespace on a system. If it cannot find a clearinghouse for the namespace you entered, it displays the following message:

There is no clearinghouse on this DNS Server for the namespace
you specified in your DECdns fullname. To proceed with this rename,
you may now provide a different DECdns fullname -- one that is
in a namespace displayed above.

If you wish to use a namespace or clearinghouse name not
previously known to this DNS Server, then this rename cannot
proceed until you have manually ensured that the existing
clearinghouse has been deleted.

* Do you want to provide a different DECdns fullname? [YES]:

If you answer YES, the procedure returns to the DECdns fullname prompt and, after you enter a DECdns full name using the proper namespace, configuration dialog processing continues:

* Enter the full name for directory service LOCAL [LOCAL:.ASHFLD] :
* What is the synonym name for this node? [ASHFLD] :
* Naming cache timeout value? [30-00:00:00] :
* Session Control Address Update Interval ? [10] :
* Naming cache checkpoint interval? [08:00:00] :

If you answer NO, the procedure displays the following message and aborts the rename operation:

  Please refer to the DECnet-Plus DECdns Management manual,
  for instructions on Deleting a Clearinghouse before invoking
  NET$CONFIGURE again to rename this DNS Server.

%NET$CONFIGURE-I-LASTTRANSABORT, last transaction aborted

Namespace Selection Processing

The procedure calls dns$configure.com twice: first, to ensure that the system is configured with the Local namespace as primary, then to configure the system with the DECdns namespace as primary:

sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
Your default namespace nickname is LOCAL.
Your default namespace NSCTS is 08-00-2B-0D-C0-9D-5F-FA-A9-88-43-46-95-00.
sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
Your default namespace nickname is VSI.
Your default namespace NSCTS is 00-00-F8-25-5A-72-D1-9D-2D-09-04-3C-A3-00.

Namespace Configuration Processing

Based on the answers provided during configuration dialog processing, the configuration procedure executes the new name service searchpath NCL script, renames the node, modifies the Local namespace entry, flushes the CDI cache, updates the node’s address towers, and updates the backtranslation softlink for the node:

%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to VSI:.ASHFLD
Directory Service: Local name file
Modifying the node: LOCAL:.ASHFLD
Modifying the node towers

%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries
%NET$CONFIGURE-I-CHECKPOINTWAIT, waiting for CDI to write the node name to the CDI cache file
%NET$CONFIGURE-I-CHECKPOINTDONE, the node name has been written to SYS$SYSTEM:DECNET$CDI_CACHE.DAT
%NET$CONFIGURE-I-TOWERSUPDATED, updated address towers for node
%NET$CONFIGURE-E-BCKTRNUPDATED, updated backtranslation softlink for node

The procedure then displays the configuration summary, recalculates the NCL script file checksums, and redisplays the main options menu:

   Summary of Configuration
Node Information:
   Node Type:                 ENDNODE
   Directory Services Chosen: DECDNS
   Primary Directory Service: DECDNS
   DECdns Full name:          VSI:.ASHFLD
   DECdns Node Type:          Server
   Node Synonym:              ASHFLD
   Phase IV Address:          24.121
   Phase IV Prefix:           49::
   Autoconfiguration of Network Addresses: Enabled
   Session Control Address Update Interval: 10
   Routing ESHello Timer:     600
   Routing ES Cache Size:     512

.
.
.
%NET$CONFIGURE-I-MODCHECKSUM, checksumming NCL management scripts modified by NET$CONFIGURE
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration completed

   Configuration Options for Node ASHFLD
   [0] Exit this procedure
   [1] Perform an entire configuration
   [2] Change naming information

This section describes how to configure a DECdns server to run with the primary directory service set to a namespace other than DECdns.

Configuration Dialog Processing

The following example shows the first portion of the dialog used to change the node from using DECdns as the primary directory service to using the Local namespace as the primary directory service (DOMAIN as primary is virtually identical):

* Which configuration option to perform? [1] : 2
* Enter the directory services to use on the system [DECDNS,LOCAL] : local,decdns

At this point, the configuration procedure displays a message indicating that VSI strongly recommends using DECdns as the primary directory service on DECdns servers:

Hewlett-Packard recommends that you specify DECdns as the
primary naming service on a DECdns server, but the list of
directory services you entered does not start with DECdns.

Answer NO to the following question if you want to ignore this
recommendation and proceed using the list of directory services
you just entered.

If you take the default, you will be prompted to re-enter your
list of directory services so that you may enter DECdns as the
first service in that list.

* Do you want DECdns as the primary naming service on this DECdns server? [YES]:

If you answer YES, the procedure again prompts you for the directory services list. If you answer NO, your original order is accepted and the dialog continues:

* Enter the full name for directory service LOCAL [LOCAL:.ASHFLD] :
* Enter the full name for directory service DECDNS [VSI:.ASHFLD]:

Because you have specified a DECdns name on a system that is already configured as a DECdns server, the procedure checks the server’s clearinghouses to make sure that you are specifying a namespace already served by this system:

NET$CONFIGURE is searching for pre-existing clearinghouses on this DNS Server.

Clearinghouse: VSI:.VSI_CH

The net$configure procedure does not support creation of more than one namespace on a system. If it cannot find a clearinghouse for the namespace you entered, it displays the following message:

There is no clearinghouse on this DNS Server for the namespace
you specified in your DECdns fullname. To proceed with this rename,
you may now provide a different DECdns fullname -- one that is
in a namespace displayed above.

If you wish to use a namespace or clearinghouse name not
previously known to this DNS Server, then this rename cannot
proceed until you have manually ensured that the existing
clearinghouse has been deleted.

* Do you want to provide a different DECdns fullname? [YES]:

If you answer YES, the procedure returns to the DECdns fullname prompt and, after entering a DECdns full name using the proper namespace, configuration dialog processing continues:

* Enter the full name for directory service DECDNS [VSI:.ASHFLD]:
* What is the synonym name for this node? [ASHFLD] :
* Naming cache timeout value? [30-00:00:00] :
* Session Control Address Update Interval ? [10] :
* Naming cache checkpoint interval? [08:00:00] :

If you answer NO, the procedure displays the following message and aborts the rename operation:

  Please refer the DECnet-Plus DECdns Management manual,
  for instructions on Deleting a Clearinghouse before invoking
  NET$CONFIGURE again to rename this DNS Server.

%NET$CONFIGURE-I-LASTTRANSABORT, last transaction aborted

Namespace Selection Processing

If you choose to configure the DECdns name service as a secondary service, the configuration procedure modifies the DECdns namespace on the system to allow access by the renamed server. It does this by adding access for the LOCAL or DOMAIN namespace based on which namespace is primary. The procedure displays the following message:

NET$CONFIGURE is searching for pre-existing clearinghouses on this DNS Server in order to set up access control.

The procedure then calls the dns$configure.com procedure to configure the DECdns clerk for the new primary namespace:

sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
Your default namespace nickname is LOCAL.
Your default namespace NSCTS is 08-00-2B-0D-C0-9D-5F-FA-A9-88-43-46-95-00

If the net$configure procedure is not successful in setting the new access information, it displays the following message and aborts the transaction:

   ERROR: NET$CONFIGURE did not succeed in setting up access
   control for pre-existing clearinghouses on this DNS Server.
%NET$CONFIGURE-I-LASTTRANSABORT, last transaction aborted

   Configuration Options for Node ASHFLD
   [0] Exit this procedure
   [1] Perform an entire configuration
   [2] Change naming information
.
.
.

Namespace Configuration Processing

Based on the answers provided during configuration dialog processing, the configuration procedure executes the new name searchpath NCL script, modifies the Local namespace entry, renames the node, and flushes the cache:

Directory Service: Local name file

Modifying the node: LOCAL:.ASHFLD
Modifying the node towers

%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to LOCAL:.ASHFLD
%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries

The procedure then displays the configuration summary, recalculates the NCL script file checksums, and redisplays the main options menu:

   Summary of Configuration
Node Information:
   Directory Services Chosen: LOCAL,DECDNS
   Primary Directory Service: LOCAL
   DECdns Full name: VSI:.ASHFLD
   Local Full name: LOCAL:.ASHFLD
   Node Synonym: ASHFLD
   Phase IV Address: 24.900
   Phase IV Prefix: 49::
   DECdns Node Type: Server
   Session Control Address Update Interval: 10
   Routing Node Type: ENDNODE
   Autoconfiguration of Network Addresses: Enabled
   Routing ESHello Timer: 600
   Routing ES Cache Size: 512

.
.
.
%NET$CONFIGURE-I-MODCHECKSUM, checksumming NCL management scripts modified by NET$CONFIGURE
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration completed

   Configuration Options for Node ASHFLD
   [0] Exit this procedure
   [1] Perform an entire configuration
   [2] Change naming information
.
.
.

To configure additional DECdns servers into an existing namespace, you must use the DECdns configuration program, sys$system:dns$configure.exe. Be sure to refer to the VSI DECnet-Plus for OpenVMS DECdns Management Guide for DECdns access control information and for complete information about using the DECdns configuration program to configure a DECdns server into an existing namespace.

DECdts binary time values are based on Coordinated Universal Time (UTC), an international time standard that has largely replaced Greenwich Mean Time (GMT) as a reference. For most measurement purposes, UTC is the equivalent of GMT. Time zones are still determined by their relationship to the prime meridian in Greenwich, England. The local time in each time zone or locale is determined by its offset, or differential, from the Greenwich time zone. This value is commonly expressed as a time differential factor (TDF) of a positive or negative number of hours.

When you initially configure an OpenVMS system, you must determine its geographical location and designate its time zone rule (TZR), which is based on the location. The TZR contains the abbreviated name of the system’s time zone and the applicable TDF, so that DECdts can calculate UTC from the system (local) time during the initial configuration of the DECdts software. The TZR also contains information on any seasonal adjustments to the TDF that normally apply in the selected time zone.

If you want to select the commonly accepted TZR for a given area and system, you can use the net$configure procedure menus to select the geographical location of the system. Based on your selection, the net$configure procedure automatically sets the TZR. After you configure your system, it displays the local time even though the DECdts software uses UTC in the background. Because the default value of the DECdts management attribute Automatic TDF Change is set to TRUE, DECdts also changes the displayed local time automatically if there is a seasonal adjustment to the system’s TDF.

Additionally, when you reconfigure the DECdts software, you are given the option of setting the system’s time to UTC time.

The following resources provide additional information about time management and use on OpenVMS systems:

DTSS$CONFIG-I-LOGS Deassigning system timezone logicals

DTSS$CONFIG-I-STOPDTS Deleting the DTSS Entity

Node 0 DTSS
at 1995-08-04-18:36:19.740+00:00Iinf

Node 0 DTSS
at 1995-08-04-18:36:23.960+00:00Iinf

The dtss$config procedure then invokes the dtss$install_timezone_rule procedure. This procedure is also invoked during the initial system configuration. However, during initial configuration the procedure usually gets the time zone rule from the SYS$LOCALTIME system logical name so no menu is displayed. In a reconfiguration, the procedure is called with a parameter that forces it to override the SYS$LOCALTIME system logical name and display an options menu:

Timezone Options:

[0] Exit Timezone Configuration
[1] Choose a timezone using menus
[2] Use Universal Coordinated Time (UTC)
[3] Define your own timezone rule

* Enter an option number [1] :

Option 1 of the Timezone Options menu invokes the OpenVMS sys$manager:utc$time_setup procedure to allow you to choose the time zone rule for the system by using a hierarchy of geographically-based menus. DECdts uses the time zone you select to determine the time zone rule it should use to automatically convert UTC to the local time whenever the time is displayed.

To specify a time zone rule by choosing your geographical region, select option 1 from the timezone options menu:

* Enter an option number [1] :

The procedure displays a menu of continental regions:

Configuring the Local Time Zone
TIME ZONE SPECIFICATION -- MAIN Time Zone Menu    "*" indicates a menu
0* GMT
1* AFRICA     17) EST       33) IRAN       49) PORTUGAL
2* AMERICA    18) EST5EDT   34) ISRAEL     50) PRC
3* ANTARCTICA 19* ETC       35) JAMAICA    51) PST8PDT
4* ARCTIC     20* EUROPE    36) JAPAN      52) ROC
5* ASIA       21) FACTORY   37) KWAJALEIN  53) ROK
6* ATLANTIC   22) GB-EIRE   38) LIBYA      54) SINGAPORE
7* AUSTRALIA  23) GB        39) MET        55* SYSTEMV
8* BRAZIL     24) GMT-0     40* MEXICO     56) TURKEY
9* CANADA     25) GMT       41* MIDEAST    57) UCT
10) CET       26) GMT0      42) MST        58) UNIVERSAL
11* CHILE     27) GMTPLUS0  43) MST7MDT    59* US
12) CST6CDT   28) GREENWICH 44) NAVAJO     60) UTC
13) CUBA      29) HONGKONG  45) NZ-CHAT    61) W-SU
14) EET       30) HST       46) NZ         62) WET
15) EGYPT     31) ICELAND   47* PACIFIC    63) ZULU
16) EIRE      32* INDIAN    48) POLAND

Press "Return" to redisplay, enter "=" to search or "?" for help, or
Select the number above that best represents the desired time zone: 59

US Time Zone Menu "*"     indicates a menu
0* RETURN TO MAIN TIME ZONE MENU
1) ALASKA     5) EAST-INDIANA     9) MICHIGAN    13) SAMOA
2) ALEUTIAN   6) EASTERN         10) MOUNTAIN
3) ARIZONA    7) HAWAII          11) PACIFIC-NEW
4) CENTRAL    8) INDIANA-STARKE  12) PACIFIC

Press "Return" to redisplay, enter "=" to search or "?" for help, or
Select the number above that best represents the desired time zone: 6

You selected US / EASTERN as your time zone.
Is this correct? (Yes/No) [YES]:

Enter the option (and, if necessary, the suboption) corresponding to the region where the system resides. In the example, the system is in the eastern United States. After you make a selection, the following actions occur:

These actions result in the following display:

DTSS$CONFIG-I-LOGS Defining system timezone logicals
DTSS-I-SETTDF DTSS$SERVICE set new timezone differential
DTSS$CONFIG-I-SETLCL Setting Local Clock

%RUN-S-PROC_ID, identification of created process is 00000059
Node 0 DTSS at 1995-02-25-08:17:29.520-05:00Iinf
Node 0 DTSS at 1995-02-25-08:17:30.790-05:00Iinf
Node 0 DTSS at 1995-02-25-08:17:39.978-05:00I0.327
Node 0 DTSS at 1995-02-25-08:17:45.868-05:00I0.328
Characteristics
Automatic TDF Change = True
Node 0 DTSS at 1995-02-25-08:17:51.898-05:00I0.328
DTSS$CONFIG-I-STARTDTS Restarting the DTSS Entity

%RUN-S-PROC_ID, identification of created process is 0000006B
Node 0 DTSS at 1995-02-25-08:18:06.138-05:00Iinf
Node 0 DTSS at 1995-02-25-08:18:07.488-05:00Iinf

This completes changes to the DECdts configuration using option 1. The net$configure procedure returns to the main options menu.

If your system is located in the GMT time zone or Antarctica, or if you do not want to make seasonal adjustments to the TDF, you may want to use UTC as your system’s local time. You can also configure all network systems with UTC if you consider local time irrelevant for your applications. If you select UTC as the local time and later enter the NCL command show dtss current time, the local time displayed has a TDF of 0 (zero).

To use UTC as your system’s local time, select option 2:

* Enter an option number [1] : 2

The subsequent actions are identical to those shown following the selection of a time zone in the previous section.

This completes changes to the DECdts configuration using option 2. The net$configure procedure returns to the main options menu.

The net$configure procedure no longer allows you to create a customized time zone rule. To create a customized time zone rule, refer to the additional documentation resources referenced in Section 7.9.2, “Selecting the DECdts Configuration Option”. In particular, the VSI C Run-Time Library Utilities Reference Manual discusses using the Zone Information Compiler (ZIC) to create new binary time zone files. Once you have created a new file and moved it to the appropriate place in the time zones directory, you can select the time zone in the same manner you would select any other time zone.

If you select option 3, the procedure displays a short description of the process used to create a custom time zone rule.

If you are deleting an application, the procedure displays the following prompt:

* Are you sure you want to DELETE this application? [NO]:

Answer YES if you want to delete the application. Answer NO if you want to keep the application. If you answer NO, the procedure informs you it has canceled the delete operation:

%NET$CONFIGURE-I-DELETECAN, delete operation canceled

If you are adding an application, the configuration procedure asks a series of questions to define the application:

If you want to delete a MOP client, the procedure displays the following prompt:

* Are you sure you want to DELETE this client? :

Answer YES if you want to delete the MOP client. Answer NO if you want to keep the MOP client. If you answer NO, the procedure informs you it has canceled the delete operation:

%NET$CONFIGURE-I-DELETECAN, delete operation canceled

If you are adding a MOP client, the configuration procedure asks a series of questions to define the MOP client:

If you are removing a node from the specified alias, the procedure displays the following prompt:

* Are you sure you want to DELETE this alias? [NO]:

Answer YES if you want to remove the system from this alias. Answer NO if you want the system to remain a member of this alias. If you answer NO, the procedure informs you it has canceled the delete operation:

%NET$CONFIGURE-I-DELETECAN, delete operation canceled

If you are adding a node to a cluster alias, the dialog for a configuration modification is identical to the initial dialog. See Section 6.12, “Configuring a Cluster Alias” for the entire alias dialog.

To autoconfigure a Phase IV cluster member, select option 1 from the satellite options menu:

* Which configuration option to perform? [1] : 1

If you select this option, the procedure creates a short command file that invokes net$configure with the parameters necessary to complete the initial configuration. This command file is invoked the next time that the satellite system is rebooted. Most of the parameters are derived from the defaults within the net$configure procedure. However, you must supply a small number of parameters directly.

3. To configure the cluster satellite systems, the configuration procedure needs to know the system root directories from which the satellites boot. Normally, the system root directories are on sys$sysdevice. The device given in response to this question is searched for all system roots. Those found that do not contain a Phase V checksum database are assumed to be Phase IV nodes and are candidates for autoconfiguration. Enter the device containing the system roots for cluster members:

* Device containing system roots [SYS$SYSDEVICE:] :

The procedure displays the following message as it scans the indicated system root device for system root directories:

Scanning SYS$SYSDEVICE: for Phase IV system root directories...

If it finds a directory it does some additional checking to verify that it has found a valid system root directory. If the directory is valid, it uses the member’s modparams.dat file to obtain the default values for some of the following questions. If no roots are found on the device supplied (or if all the roots found have already been autoconfigured), the procedure asks if it should scan any additional devices for system roots:

* Are there any more disk devices containing system roots? [NO] :

Answer YES if any additional devices contain system root directories. Answer NO to return to the satellite configuration menu.

The procedure resumes the scan of the system root device. If any more system roots are found, the procedure repeats the previous three questions for each satellite system root found.

Once the procedure completes the scan of system roots on the device you indicated, it asks you if there are any other devices containing system roots:

* Are there any more disk devices containing system roots? [No] :

Answer YES if you wish to specify another device containing system roots. Answer NO if there are no more devices containing system roots.

After completing all requested autoconfigurations, the procedure returns to the satellite options menu.

Normally, the configuration procedure is used to configure the local node. You can use the procedure to modify satellite nodes that have already been configured (either by using option 1 and rebooting the satellite or by running net$configure directly on the node). This option allows you to direct the configuration procedure to perform all future operations on a satellite node instead of the local node. Note that not all configuration options are available when configuring a satellite node.

To direct the configuration procedure to perform all future operations on a satellite node, select option 2 from the satellite options menu:

* Which configuration option to perform? [1] : 2

The procedure asks you for the name of the cluster member that you want to configure:

* Cluster node name to be configured: : FASTER

Enter the simple name of the cluster member you want to configure.

The next two questions determine the location of the satellite’s system root. The first question asks for the disk device on which the cluster member’s system root resides. The default is either sys$sysdevice or the root device found for that system in the local system’s net$mop_client_startup.ncl script file.

* Device for FASTER root: [SYS$SYSDEVICE] :

Enter the device containing the system’s root.

Next, the procedure asks you for the system root directory from which the member loads:

* Directory for FASTER root: : SYS2

Enter the system root directory in the form SYSxxxx, where xxxx is a hexadecimal number.

The procedure verifies that the cluster member has been configured (either through the autoconfigure option discussed in suboption 1 or by running net$configure directly on the satellite). If the autoconfigure file created by suboption 1 is found but no other configuration files are found, the procedure displays the following message:

********************************************************************
This cluster member has been flagged for autoconfiguration of
OSI/DECnet Phase V, but has not yet executed the autoconfiguration
procedure. In order to do this, the system must be rebooted, or
SYS$STARTUP:NET$STARTUP.COM must be executed.
********************************************************************

If the procedure finds no configuration files and no autoconfigure file, it displays the following message:

********************************************************************
This cluster member has not yet been configured for OSI/DECnet
Phase V. You may either select option [1] to autoconfigure this
system, or run NET$CONFIGURE on this system.
********************************************************************

If the proper configuration information is found, the procedure returns to the main options menu to allow you to modify the cluster member’s configuration. Before net$configure returns to the main options menu, it warns you that all subsequent options will be applied to the cluster member you specified:

%NET$CONFIGURE-I-VERCHECKSUM, verifying checksums
All configuration options will be applied to cluster node FASTER

Note that the following main menu options are not available when configuring satellite nodes: option 1 (Perform an entire configuration), option 3 (Configure Devices on this machine), and option 5 (Configure Timezone Differential Factor).

If you select option 3, it clears the action of option 2; that is, all subsequent net$configure modifications are made to the local system (as when net$configure was started).

To direct the configuration procedure to perform all future operations on the local node, select option 3 from the satellite options menu:

* Which configuration option to perform? [1] : 3

All subsequent configuration tasks now affect the local node. All options in the main options menu are again available.

To exit the satellite options menu, enter 0 and press Return. The procedure returns you to the main options menu.

You can use user-defined site-specific NCL scripts for the Event Dispatcher, MOP client, application, and search path entities. (See Section B.1.1, “Creating a Site-Specific Search Path NCL Script” for further information about creating the site-specific search path script.)

The network startup procedure (net$startup.com) calls four site-specific NCL scripts (if they exist) when the network is started. These scripts must be in sys$manager. They are called immediately after their net$configure generated counterparts are executed. The following table lists the scripts and their counterparts.

net$event_local.ncl

net$event_startup.ncl

net$application_local.ncl

net$application_startup.ncl

net$mop_client_local.ncl

net$mop_client_startup.ncl

net$searchpath_local.ncl

net$searchpath_startup.ncl

Such user-defined scripts are user-maintained and thus are not overwritten or deleted by net$configure. VSI recommends that, whenever possible, you place your site-specific changes in these user-defined NCL scripts.

VSI provides a template for the net$event_local.ncl file. The template is located in the sys$manager: directory with the file name net$event_local.template. Simply copy the file to net$event_local.ncl and make any changes for your system.

If you must make changes to the standard NCL scripts and you want to retain your modifications after invoking net$configure, you can either manually edit the NCL script to replace the user modifications or rename the appropriate net$entity_startup.ncl-old script back to net$entity_startup.ncl. Be sure to incorporate any new changes as well. The net$configure procedure flags these modifications the next time it checksums the scripts.

There are three types of X.25 for OpenVMS systems:

Refer to the VSI DECnet-Plus for OpenVMS Introduction and User’s Guide for an explanation of X.25 fundamentals.

The types of systems you can configure depend on the licenses that you have installed. Table 8.2, “X.25 for OpenVMS VAX Configurations and License Requirements” summarizes the various possible configurations.

To start the X.25 configuration program, log in to any account that has OPER and SYSPRV privileges and enter the command:

$ @sys$manager:psi$configure

The configuration program consists of a number of sections, each corresponding to a logical group of information. Each section consists of one or more screens on which you can enter data. All sections (with the exception of the X.29 and Mail support section) also have an introductory information screen.

Most sections are optional. These sections begin with a question of the form: "Do you want to set up X?" If you select Yes, you go through the rest of the section. If you select No, you go directly to the next new section, although you can decide at a later stage to complete that section (See Section 8.4.5, “Accessing the Options Menu”).

The methods available for moving between sections depend on whether you are creating or modifying a configuration.

When creating a configuration, an Options Menu is displayed when you complete the last data entry screen in a section. This menu includes options that allow you to move to the next uncompleted section or to move to a previously completed section (via the Sections Menu):

Full details of the Options Menu are provided in Section 8.4.5, “Accessing the Options Menu”.

When modifying a configuration, a specific section can be selected from the Sections Menu. The Sections Menu is displayed automatically after you select the option Modify an existing configuration script, or can be accessed from the Options Menu of the current section by selecting the option ‘‘Go to Sections Menu’’ (refer to Section 8.4.5, “Accessing the Options Menu”).

Table 8.3, “Available Keys Used by the X.25 Configuration Program” lists the keys you can use when running the configuration program.

Note that if your terminal does not support cursor keys, you cannot move between fields, and therefore you cannot run the configuration program from the terminal.

To use the cursor keys, you must ensure that the terminal device type is set correctly so that it reflects the terminal being emulated.

To set the terminal device type, enter the command:

$ SET TERM/DEVICE=terminal_type

where terminal_type is specified as VT300, VT200, and so on.

When you leave the last screen in a section, an Options menu appears.

Generally, the Options menu for a section provides the following choices:

where x is the item you created in that section.

For example, the PVC Options menu provides the following choices:

Continue to a new section
Add a PVC
Modify a PVC
Delete a PVC
Go to Sections menu

These options are described here.

Continue to a new section

Choose this option when you finish entering or modifying information in the current section. The configuration program then displays the first screen in the next unseen section.

Add an X

Choose this option to add another item in this section.

For example, when you finish entering data for a PVC and you want to add another PVC, choosing this option takes you back to the first data entry screen for PVCs.

Modify an X

Choose this option to modify some or all of the information you provided previously about an item.

For example, if you choose this option from the PVC Options menu, the next screen lists all the PVCs defined so far. You select one of these (PVC1, for example), and then go back to the first data entry screen for PVCs. The fields contain the information you provided when you first set up PVC1. You can modify any of this information. Use the Next Screen key and the Prev Screen key to move between screens that you do not want to alter.

Delete an X

Choose this option to delete an item in this section.

For example, if you choose this option from the PVC Options menu, a list of all PVCs defined on your system so far appears on the screen. Select one of these (PVC2, for example), and you are asked for confirmation that this is the one you want to delete.

Go to Sections Menu

Choose this option to go to the Sections menu. From there you can go on to the Options menu of a different section.

You can get help at any time during the program by pressing the Help key.

The final section in the configuration program is Create the NCL Script. You are asked if you want to create the NCL script.

If, for some reason, the program cannot create the NCL script, an error message appears at the foot of the screen and the cursor stays on the question, "Do you wish to create the NCL scripts now?" You must correct the problem before you answer YES to this question.

To quit from the configuration program without creating an NCL script:

Once the configuration program has created the configuration file containing the NCL scripts, the Main Menu is redisplayed.

To leave the configuration program, select the option Exit this program.

This section describes the checks you must make before running the CTP.

Privileges Required

System Quotas Required

X.25 Software

To check, enter the following commands.

Direct Connect or Connector system:

ncl> show x25 protocol dte dte-name state

Client system:

ncl> show node connector-node-id -
_ncl> x25 protocol dte dte-name state

If the status of your DTE is not shown as RUNNING, wait for 2 minutes and try again. If your DTE is still not RUNNING, refer to the VSI X.25 for OpenVMS Problem Solving.

Remote System

You can run the CTP either interactively or as a network object. When the CTP is set up as a network object, it can only handle incoming calls (either from a remote system or calls that have been looped back from the PSDN).

$ run sys$test:psi$ctp

$ mcr ncl @sys$test:psi$ctp_add_netobj

$ mcr ncl @sys$test:psi$ctp_rem_netobj