HP OpenVMS Cluster Systems

7.12 Using a Common Command Procedure

Once you have created queues, you must start them to begin processing batch and print jobs. In addition, you must make sure the queues are started each time the system reboots, by enabling autostart for autostart queues or by entering START/QUEUE commands for nonautostart queues. To do so, create a command procedure containing the necessary commands.

7.12.1 Command Procedure

You can create a common command procedure named, for example, QSTARTUP.COM, and store it on a shared disk. With this method, each node can share the same copy of the common QSTARTUP.COM procedure. Each node invokes the common QSTARTUP.COM procedure from the common version of SYSTARTUP. You can also include the commands to start queues in the common SYSTARTUP file instead of in a separate QSTARTUP.COM file.

7.12.2 Examples

Example 7-1 shows commands used to create OpenVMS Cluster queues.

Example 7-1 Sample Commands for Creating OpenVMS Cluster Queues

$ (1) $ DEFINE/FORM LN_FORM 10 /WIDTH=80 /STOCK=DEFAULT /TRUNCATE $ DEFINE/CHARACTERISTIC 2ND_FLOOR 2 . . . (2) $ INITIALIZE/QUEUE/AUTOSTART_ON=(JUPITR::LPA0:)/START JUPITR_PRINT $ INITIALIZE/QUEUE/AUTOSTART_ON=(SATURN::LPA0:)/START SATURN_PRINT $ INITIALIZE/QUEUE/AUTOSTART_ON=(URANUS::LPA0:)/START URANUS_PRINT . . . (3) $ INITIALIZE/QUEUE/BATCH/START/ON=JUPITR:: JUPITR_BATCH $ INITIALIZE/QUEUE/BATCH/START/ON=SATURN:: SATURN_BATCH $ INITIALIZE/QUEUE/BATCH/START/ON=URANUS:: URANUS_BATCH . . . (4) $ INITIALIZE/QUEUE/START - _$ /AUTOSTART_ON=(JUPITR::LTA1:,SATURN::LTA1,URANUS::LTA1) - _$ /PROCESSOR=LATSYM /FORM_MOUNTED=LN_FORM - _$ /RETAIN=ERROR /DEFAULT=(NOBURST,FLAG=ONE,NOTRAILER) - _$ /RECORD_BLOCKING LN03$PRINT $ $ INITIALIZE/QUEUE/START - _$ /AUTOSTART_ON=(JUPITR::LTA2:,SATURN::LTA2,URANUS::LTA2) - _$ /PROCESSOR=LATSYM /RETAIN=ERROR - _$ /DEFAULT=(NOBURST,FLAG=ONE,NOTRAILER) /RECORD_BLOCKING - _$ /CHARACTERISTIC=2ND_FLOOR LA210$PRINT $ (5) $ ENABLE AUTOSTART/QUEUES/ON=SATURN $ ENABLE AUTOSTART/QUEUES/ON=JUPITR $ ENABLE AUTOSTART/QUEUES/ON=URANUS (6) $ INITIALIZE/QUEUE/START SYS$PRINT - _$ /GENERIC=(JUPITR_PRINT,SATURN_PRINT,URANUS_PRINT) $ (7) $ INITIALIZE/QUEUE/BATCH/START SYS$BATCH - _$ /GENERIC=(JUPITR_BATCH,SATURN_BATCH,URANUS_BATCH) $

Following are descriptions of each command or group of commands in Example 7-1.

Command Description

(1) Define all printer forms and characteristics.

(2) Initialize local print queues. In the example, these queues are autostart queues and are started automatically when the node executes the ENABLE AUTOSTART/QUEUES command. Although the /START qualifier is specified to activate the autostart queues, they do not begin processing jobs until autostart is enabled.
To enable autostart each time the system reboots, add the ENABLE AUTOSTART/QUEUES command to your queue startup command procedure, as shown in Example 7-2.

(3) Initialize and start local batch queues on all nodes, including satellite nodes. In this example, the local batch queues are not autostart queues.

(4) Initialize queues for remote LAT printers. In the example, these queues are autostart queues and are set up to run on one of three nodes. The queues are started on the first of those three nodes to execute the ENABLE AUTOSTART command.
You must establish the logical devices LTA1 and LTA2 in the LAT startup command procedure LAT$SYSTARTUP.COM on each node on which the autostart queue can run. For more information, see the description of editing LAT$SYSTARTUP.COM in the HP OpenVMS System Manager's Manual.
Although the /START qualifier is specified to activate these autostart queues, they will not begin processing jobs until autostart is enabled.

(5) Enable autostart to start the autostart queues automatically. In the example, autostart is enabled on node SATURN first, so the queue manager starts the autostart queues that are set up to run on one of several nodes.

(6) Initialize and start the generic output queue SYS$PRINT. This is a nonautostart queue (generic queues cannot be autostart queues). However, generic queues are not stopped automatically when a system is shut down, so you do not need to restart the queue each time a node reboots.

(7) Initialize and start the generic batch queue SYS$BATCH. Because this is a generic queue, it is not stopped when the node shuts down. Therefore, you do not need to restart the queue each time a node reboots.

Command	Description
(1)	Define all printer forms and characteristics.
(2)	Initialize local print queues. In the example, these queues are autostart queues and are started automatically when the node executes the ENABLE AUTOSTART/QUEUES command. Although the /START qualifier is specified to activate the autostart queues, they do not begin processing jobs until autostart is enabled. To enable autostart each time the system reboots, add the ENABLE AUTOSTART/QUEUES command to your queue startup command procedure, as shown in Example 7-2.
(3)	Initialize and start local batch queues on all nodes, including satellite nodes. In this example, the local batch queues are not autostart queues.
(4)	Initialize queues for remote LAT printers. In the example, these queues are autostart queues and are set up to run on one of three nodes. The queues are started on the first of those three nodes to execute the ENABLE AUTOSTART command. You must establish the logical devices LTA1 and LTA2 in the LAT startup command procedure LAT$SYSTARTUP.COM on each node on which the autostart queue can run. For more information, see the description of editing LAT$SYSTARTUP.COM in the HP OpenVMS System Manager's Manual. Although the /START qualifier is specified to activate these autostart queues, they will not begin processing jobs until autostart is enabled.
(5)	Enable autostart to start the autostart queues automatically. In the example, autostart is enabled on node SATURN first, so the queue manager starts the autostart queues that are set up to run on one of several nodes.
(6)	Initialize and start the generic output queue SYS$PRINT. This is a nonautostart queue (generic queues cannot be autostart queues). However, generic queues are not stopped automatically when a system is shut down, so you do not need to restart the queue each time a node reboots.
(7)	Initialize and start the generic batch queue SYS$BATCH. Because this is a generic queue, it is not stopped when the node shuts down. Therefore, you do not need to restart the queue each time a node reboots.

7.12.3 Example

Example 7-2 illustrates the use of a common QSTARTUP command procedure on a shared disk.

Example 7-2 Common Procedure to Start OpenVMS Cluster Queues

$! $! QSTARTUP.COM -- Common procedure to set up cluster queues $! $! (1) $ NODE = F$GETSYI("NODENAME") $! $! Determine the node-specific subroutine $! $ IF (NODE .NES. "JUPITR") .AND. (NODE .NES. "SATURN") .AND. (NODE .NES. "URANUS") $ THEN $ GOSUB SATELLITE_STARTUP $ ELSE (2) $! $! Configure remote LAT devices. $! $ SET TERMINAL LTA1: /PERM /DEVICE=LN03 /WIDTH=255 /PAGE=60 - /LOWERCASE /NOBROAD $ SET TERMINAL LTA2: /PERM /DEVICE=LA210 /WIDTH=255 /PAGE=66 - /NOBROAD $ SET DEVICE LTA1: /SPOOLED=(LN03$PRINT,SYS$SYSDEVICE:) $ SET DEVICE LTA2: /SPOOLED=(LA210$PRINT,SYS$SYSDEVICE:) (3) $ START/QUEUE/BATCH 'NODE'_BATCH $ GOSUB 'NODE'_STARTUP $ ENDIF $ GOTO ENDING $! $! Node-specific subroutines start here $! (4) $ SATELLITE_STARTUP: $! $! Start a batch queue for satellites. $! $ START/QUEUE/BATCH 'NODE'_BATCH $ RETURN $! (5) $JUPITR_STARTUP: $! $! Node-specific startup for JUPITR:: $! Setup local devices and start nonautostart queues here $! $ SET PRINTER/PAGE=66 LPA0: $ RETURN $! $SATURN_STARTUP: $! $! Node-specific startup for SATURN:: $! Setup local devices and start nonautostart queues here $! . . . $ RETURN $! $URANUS_STARTUP: $! $! Node-specific startup for URANUS:: $! Setup local devices and start nonautostart queues here $! . . . $ RETURN $! $ENDING: (6) $! Enable autostart to start all autostart queues $! $ ENABLE AUTOSTART/QUEUES $ EXIT

Following are descriptions of each phase of the common QSTARTUP.COM command procedure in Example 7-2.

Command Description

(1) Determine the name of the node executing the procedure.

(2) On all large nodes, set up remote devices connected by the LAT. The queues for these devices are autostart queues and are started automatically when the ENABLE AUTOSTART/QUEUES command is executed at the end of this procedure.
In the example, these autostart queues were set up to run on one of three nodes. The queues start when the first of those nodes executes the ENABLE AUTOSTART/QUEUES command. The queue remains running as long as one of those nodes is running and has autostart enabled.

(3) On large nodes, start the local batch queue. In the example, the local batch queues are nonautostart queues and must be started explicitly with START/QUEUE commands.

(4) On satellite nodes, start the local batch queue.

(5) Each node executes its own subroutine. On node JUPITR, set up the line printer device LPA0:. The queue for this device is an autostart queue and is started automatically when the ENABLE AUTOSTART/QUEUES command is executed.

(6) Enable autostart to start all autostart queues.

Command	Description
(1)	Determine the name of the node executing the procedure.
(2)	On all large nodes, set up remote devices connected by the LAT. The queues for these devices are autostart queues and are started automatically when the ENABLE AUTOSTART/QUEUES command is executed at the end of this procedure. In the example, these autostart queues were set up to run on one of three nodes. The queues start when the first of those nodes executes the ENABLE AUTOSTART/QUEUES command. The queue remains running as long as one of those nodes is running and has autostart enabled.
(3)	On large nodes, start the local batch queue. In the example, the local batch queues are nonautostart queues and must be started explicitly with START/QUEUE commands.
(4)	On satellite nodes, start the local batch queue.
(5)	Each node executes its own subroutine. On node JUPITR, set up the line printer device LPA0:. The queue for this device is an autostart queue and is started automatically when the ENABLE AUTOSTART/QUEUES command is executed.
(6)	Enable autostart to start all autostart queues.

7.13 Disabling Autostart During Shutdown

By default, the shutdown procedure disables autostart at the beginning of the shutdown sequence. Autostart is disabled to allow autostart queues with failover lists to fail over to another node. Autostart also prevents any autostart queue running on another node in the cluster to fail over to the node being shut down.

7.13.1 Options

You can change the time at which autostart is disabled in the shutdown sequence in one of two ways:

Option Description

1 Define the logical name SHUTDOWN$DISABLE_AUTOSTART as follows:
$ DEFINE/SYSTEM/EXECUTIVE SHUTDOWN$DISABLE_AUTOSTART number-of-minutes

Set the value of number-of-minutes to the number of minutes before shutdown when autostart is to be disabled. You can add this logical name definition to SYLOGICALS.COM. The value of number-of-minutes is the default value for the node. If this number is greater than the number of minutes specified for the entire shutdown sequence, autostart is disabled at the beginning of the sequence.

2 Specify the DISABLE_AUTOSTART number-of-minutes option during the shutdown procedure. (The value you specify for number-of-minutes overrides the value specified for the SHUTDOWN$DISABLE_AUTOSTART logical name.)

Option	Description
1	Define the logical name SHUTDOWN$DISABLE_AUTOSTART as follows: $ DEFINE/SYSTEM/EXECUTIVE SHUTDOWN$DISABLE_AUTOSTART number-of-minutes Set the value of number-of-minutes to the number of minutes before shutdown when autostart is to be disabled. You can add this logical name definition to SYLOGICALS.COM. The value of number-of-minutes is the default value for the node. If this number is greater than the number of minutes specified for the entire shutdown sequence, autostart is disabled at the beginning of the sequence.
2	Specify the DISABLE_AUTOSTART number-of-minutes option during the shutdown procedure. (The value you specify for number-of-minutes overrides the value specified for the SHUTDOWN$DISABLE_AUTOSTART logical name.)

Reference: See the HP OpenVMS System Manager's Manual for more information about changing the time at which autostart is disabled during the shutdown sequence.

Chapter 8
Configuring an OpenVMS Cluster System

This chapter provides an overview of the cluster configuration command procedures and describes the preconfiguration tasks required before running either command procedure. Then it describes each major function of the command procedures and the postconfiguration tasks, including running AUTOGEN.COM.

8.1 Overview of the Cluster Configuration Procedures

Two similar command procedures are provided for configuring and reconfiguring an OpenVMS Cluster system: CLUSTER_CONFIG_LAN.COM and CLUSTER_CONFIG.COM. The choice depends on whether you use the LANCP utility or DECnet for satellite booting in your cluster. CLUSTER_CONFIG_LAN.COM provides satellite booting services with the LANCP utility; CLUSTER_CONFIG.COM provides satellite booting services with DECnet.

Also, to configure an Integrity server system use CLUSTER_CONFIG_LAN.COM and to configure an Alpha system, use either CLUSTER_CONFIG_LAN.COM or CLUSTER_CONFIG.COM. You can use only CLUSTER_CONFIG_LAN.COM for configuring Cluster over IP.

In a satellite environment, you may want to determine which command procedure is used for configuring a cluster. To determine whether CLUSTER_CONFIG or CLUSTER_CONFIG_LAN is used in cluster configuration, see the SYS$SYSTEM:MODPARAMS.DAT file. While configuring a cluster, the command procedure name is added as a comment in the MODPARAMS.DAT file.

During the ADD operation, a comment similar to the following is added to MODPARAMS.DAT for CLUSTER_CONFIG:

! CLUSTER_CONFIG creating for ADD operation on 4-APR-2009 14:21:00.89

For CLUSTER_CONFIG_LAN:

! CLUSTER_CONFIG_LAN creating for ADD operation on 5-APR-2009 14:21:00.89

Similar comments are added for the 'CHANGE' operation. For multiple entries in MODPARAMS.DAT, the last entry reflects the latest procedure name that is used to configure the cluster. See Section 4.5 for the factors to consider when choosing a satellite booting service.

These configuration procedures automate most of the tasks required to configure an OpenVMS Cluster system. When you invoke CLUSTER_CONFIG_LAN.COM or CLUSTER_CONFIG.COM, the following configuration options are displayed:

Add a computer to the cluster
Remove a computer from the cluster
Change a computer's characteristics
Create a duplicate system disk
Make a directory structure for a new root on a system disk
Delete a root from a system disk

By selecting the appropriate option, you can configure the cluster easily and reliably without invoking any OpenVMS utilities directly. Table 8-1 summarizes the functions that the configuration procedures perform for each configuration option.

The phrase cluster configuration command procedure, when used in this chapter, refers to both CLUSTER_CONFIG_LAN.COM and CLUSTER_CONFIG.COM. The questions of the two configuration procedures are identical except where they pertain to LANCP and DECnet.

Note: For help on any question in these command procedures, type a question mark (?) at the question.

Table 8-1 Summary of Cluster Configuration Functions
Option Functions Performed

ADD Enables a node as a cluster member:

Establishes the new computer's root directory on a cluster common system disk and generates the computer's system parameter files, (IA64VMSSYS.PAR for Integrity server systems or ALPHAVMSSYS.PAR for Alpha systems), and MODPARAMS.DAT in its SYS$SPECIFIC:[SYSEXE] directory.
Generates the new computer's page and swap files (PAGEFILE.SYS and SWAPFILE.SYS).
Sets up a cluster quorum disk (optional).
Sets disk allocation class values, or port allocation class values (Alpha only), or both, with the ALLOCLASS parameter for the new computer, if the computer is being added as a disk server. If the computer is being added as a tape server, sets a tape allocation class value with the TAPE_ALLOCLASS parameter.
Note: ALLOCLASS must be set to a value greater than zero if you are configuring an Alpha computer on a shared SCSI bus and you are not using a port allocation class.
Generates an initial (temporary) startup procedure for the new computer. This initial procedure:

Runs NETCONFIG.COM to configure the network.
Runs AUTOGEN to set appropriate system parameter values for the computer.
Reboots the computer with normal startup procedures.

If the new computer is a satellite node, the configuration procedure updates:

Network databases for the computer on which the configuration procedure is executed to add the new computer.
SYS$MANAGER:NETNODE_UPDATE.COM command procedure on the local computer (as described in Section 10.4.2).

REMOVE Disables a node as a cluster member:

Deletes another computer's root directory and its contents from the local computer's system disk. If the computer being removed is a satellite, the cluster configuration command procedure updates SYS$MANAGER:NETNODE_UPDATE.COM on the local computer.
Updates the permanent and volatile remote node network databases on the local computer.
Removes the quorum disk.

CHANGE Displays the CHANGE menu and prompts for appropriate information to:

Enable or disable the local computer as a disk server
Enable or disable the local computer as a boot server
Enable or disable IP for cluster communications on the local computer
Enable or disable the Ethernet or FDDI LAN for cluster communications on the local computer
Enable or disable a quorum disk on the local computer
Change a satellite's Ethernet or FDDI hardware address
Enable or disable the local computer as a tape server
Change the local computer's ALLOCLASS or TAPE_ALLOCLASS value
Change the local computer's shared SCSI port allocation class value
Enable or disable MEMORY CHANNEL for node-to-node cluster communications on the local computer

CREATE Duplicates the local computer's system disk and removes all system roots from the new disk.

MAKE Creates a directory structure for a new root on a system disk.

DELETE Deletes a root from a system disk.

**Table 8-1 Summary of Cluster Configuration Functions**
Option	Functions Performed
ADD	Enables a node as a cluster member: Establishes the new computer's root directory on a cluster common system disk and generates the computer's system parameter files, (IA64VMSSYS.PAR for Integrity server systems or ALPHAVMSSYS.PAR for Alpha systems), and MODPARAMS.DAT in its SYS$SPECIFIC:[SYSEXE] directory. Generates the new computer's page and swap files (PAGEFILE.SYS and SWAPFILE.SYS). Sets up a cluster quorum disk (optional). Sets disk allocation class values, or port allocation class values (Alpha only), or both, with the ALLOCLASS parameter for the new computer, if the computer is being added as a disk server. If the computer is being added as a tape server, sets a tape allocation class value with the TAPE_ALLOCLASS parameter. Note: ALLOCLASS must be set to a value greater than zero if you are configuring an Alpha computer on a shared SCSI bus and you are not using a port allocation class. Generates an initial (temporary) startup procedure for the new computer. This initial procedure: Runs NETCONFIG.COM to configure the network. Runs AUTOGEN to set appropriate system parameter values for the computer. Reboots the computer with normal startup procedures. If the new computer is a satellite node, the configuration procedure updates: Network databases for the computer on which the configuration procedure is executed to add the new computer. SYS$MANAGER:NETNODE_UPDATE.COM command procedure on the local computer (as described in Section 10.4.2).
REMOVE	Disables a node as a cluster member: Deletes another computer's root directory and its contents from the local computer's system disk. If the computer being removed is a satellite, the cluster configuration command procedure updates SYS$MANAGER:NETNODE_UPDATE.COM on the local computer. Updates the permanent and volatile remote node network databases on the local computer. Removes the quorum disk.
CHANGE	Displays the CHANGE menu and prompts for appropriate information to: Enable or disable the local computer as a disk server Enable or disable the local computer as a boot server Enable or disable IP for cluster communications on the local computer Enable or disable the Ethernet or FDDI LAN for cluster communications on the local computer Enable or disable a quorum disk on the local computer Change a satellite's Ethernet or FDDI hardware address Enable or disable the local computer as a tape server Change the local computer's ALLOCLASS or TAPE_ALLOCLASS value Change the local computer's shared SCSI port allocation class value Enable or disable MEMORY CHANNEL for node-to-node cluster communications on the local computer
CREATE	Duplicates the local computer's system disk and removes all system roots from the new disk.
MAKE	Creates a directory structure for a new root on a system disk.
DELETE	Deletes a root from a system disk.

8.1.1 Before Configuring the System

Before invoking either the CLUSTER_CONFIG_LAN.COM or the CLUSTER_CONFIG.COM procedure to configure an OpenVMS Cluster system, perform the tasks described in Table 8-2.

Table 8-2 Preconfiguration Tasks
Task Procedure

Determine whether the computer uses DECdtm. When you add a computer to or remove a computer from a cluster that uses DECdtm services, there are a number of tasks you need to do in order to ensure the integrity of your data.
Reference: See the chapter about DECdtm services in the HP OpenVMS System Manager's Manual for step-by-step instructions on setting up DECdtm in an OpenVMS Cluster system.
If you are not sure whether your cluster uses DECdtm services, enter this command sequence:
$ SET PROCESS /PRIVILEGES=SYSPRV
$ RUN SYS$SYSTEM:LMCP
LMCP> SHOW LOG

If your cluster does not use DECdtm services, the SHOW LOG command will display a "file not found" error message. If your cluster uses DECdtm services, it displays a list of the files that DECdtm uses to store information about transactions.

Ensure the network software providing the satellite booting service is up and running and all computers are connected to the LAN. For nodes that will use the LANCP utility for satellite booting, run the LANCP utility and enter the LANCP command LIST DEVICE/MOPDLL to display a list of LAN devices on the system:
$ RUN SYS$SYSTEM:LANCP
LANCP> LIST DEVICE/MOPDLL

For nodes running DECnet for OpenVMS, enter the DCL command SHOW NETWORK to determine whether the network is up and running:
$ SHOW NETWORK
Product: DECNET Node: CHBOSE Address(es): 25.169
Product: TCP/IP Node: chbose.ind.hp.com Address(es): 18.156.235.23

This example shows that the node CHBOSE is running DECnet for OpenVMS and node chbose.ind.hp.com is running TCP/IP. If DECnet has not been started, the message "SHOW-I-NONET, Network Unavailable" is displayed.
For nodes running DECnet--Plus, refer to DECnet for OpenVMS Network Management Utilities for information about determining whether the DECnet--Plus network is up and running.

Select MOP and disk servers. Every OpenVMS Cluster configured with satellite nodes must include at least one Maintenance Operations Protocol (MOP) and disk server. When possible, select multiple computers as MOP and disk servers. Multiple servers give better availability, and they distribute the work load across more LAN adapters.
Follow these guidelines when selecting MOP and disk servers:

Ensure that MOP servers have direct access to the system disk.
Ensure that disk servers have direct access to the storage that they are serving.
Choose the most powerful computers in the cluster. Low-powered computers can become overloaded when serving many busy satellites or when many satellites boot simultaneously. Note, however, that two or more moderately powered servers may provide better performance than a single high-powered server.
If you have several computers of roughly comparable power, it is reasonable to use them all as boot servers. This arrangement gives optimal load balancing. In addition, if one computer fails or is shut down, others remain available to serve satellites.
After compute power, the most important factor in selecting a server is the speed of its LAN adapter. Servers should be equipped with the highest-bandwidth LAN adapters in the cluster.
If you are interconnecting the cluster using IP, note the local LAN adapter on which the IP address will be configured and used for SCS.

Make sure you are logged in to a privileged account. Log in to a privileged account.
Rules: If you are adding a satellite, you must be logged into the system manager's account on a boot server. Note that the process privileges SYSPRV, OPER, CMKRNL, BYPASS, and NETMBX are required, because the procedure performs privileged system operations.

Coordinate cluster common files. If your configuration has two or more system disks, follow the instructions in Chapter 5 to coordinate the cluster common files.

Optionally, disable broadcast messages to your terminal. While adding and removing computers, many such messages are generated. To disable the messages, you can enter the DCL command REPLY/DISABLE=(NETWORK, CLUSTER). See also Section 10.5 for more information about controlling OPCOM messages.

Predetermine answers to the questions asked by the cluster configuration procedure. Table 8-3 describes the data requested by the cluster configuration command procedures.

**Table 8-2 Preconfiguration Tasks**
Task	Procedure
Determine whether the computer uses DECdtm.	When you add a computer to or remove a computer from a cluster that uses DECdtm services, there are a number of tasks you need to do in order to ensure the integrity of your data. Reference: See the chapter about DECdtm services in the HP OpenVMS System Manager's Manual for step-by-step instructions on setting up DECdtm in an OpenVMS Cluster system. If you are not sure whether your cluster uses DECdtm services, enter this command sequence: $ SET PROCESS /PRIVILEGES=SYSPRV $ RUN SYS$SYSTEM:LMCP LMCP> SHOW LOG If your cluster does not use DECdtm services, the SHOW LOG command will display a "file not found" error message. If your cluster uses DECdtm services, it displays a list of the files that DECdtm uses to store information about transactions.
Ensure the network software providing the satellite booting service is up and running and all computers are connected to the LAN.	For nodes that will use the LANCP utility for satellite booting, run the LANCP utility and enter the LANCP command LIST DEVICE/MOPDLL to display a list of LAN devices on the system: $ RUN SYS$SYSTEM:LANCP LANCP> LIST DEVICE/MOPDLL For nodes running DECnet for OpenVMS, enter the DCL command SHOW NETWORK to determine whether the network is up and running: $ SHOW NETWORK Product: DECNET Node: CHBOSE Address(es): 25.169 Product: TCP/IP Node: chbose.ind.hp.com Address(es): 18.156.235.23 This example shows that the node CHBOSE is running DECnet for OpenVMS and node chbose.ind.hp.com is running TCP/IP. If DECnet has not been started, the message "SHOW-I-NONET, Network Unavailable" is displayed. For nodes running DECnet--Plus, refer to DECnet for OpenVMS Network Management Utilities for information about determining whether the DECnet--Plus network is up and running.
Select MOP and disk servers.	Every OpenVMS Cluster configured with satellite nodes must include at least one Maintenance Operations Protocol (MOP) and disk server. When possible, select multiple computers as MOP and disk servers. Multiple servers give better availability, and they distribute the work load across more LAN adapters. Follow these guidelines when selecting MOP and disk servers: Ensure that MOP servers have direct access to the system disk. Ensure that disk servers have direct access to the storage that they are serving. Choose the most powerful computers in the cluster. Low-powered computers can become overloaded when serving many busy satellites or when many satellites boot simultaneously. Note, however, that two or more moderately powered servers may provide better performance than a single high-powered server. If you have several computers of roughly comparable power, it is reasonable to use them all as boot servers. This arrangement gives optimal load balancing. In addition, if one computer fails or is shut down, others remain available to serve satellites. After compute power, the most important factor in selecting a server is the speed of its LAN adapter. Servers should be equipped with the highest-bandwidth LAN adapters in the cluster. If you are interconnecting the cluster using IP, note the local LAN adapter on which the IP address will be configured and used for SCS.
Make sure you are logged in to a privileged account.	Log in to a privileged account. Rules: If you are adding a satellite, you must be logged into the system manager's account on a boot server. Note that the process privileges SYSPRV, OPER, CMKRNL, BYPASS, and NETMBX are required, because the procedure performs privileged system operations.
Coordinate cluster common files.	If your configuration has two or more system disks, follow the instructions in Chapter 5 to coordinate the cluster common files.
Optionally, disable broadcast messages to your terminal.	While adding and removing computers, many such messages are generated. To disable the messages, you can enter the DCL command REPLY/DISABLE=(NETWORK, CLUSTER). See also Section 10.5 for more information about controlling OPCOM messages.
Predetermine answers to the questions asked by the cluster configuration procedure.	Table 8-3 describes the data requested by the cluster configuration command procedures.

Contents

Index