To change the default boot adapter, you need the physical address of
the alternate LAN adapter. You use the address to update the
satellite's node definition in the DECnet or LANCP database on the MOP
servers so that they recognize the satellite (described in
Section 9.4.4).

IF the system is...

THEN...

An Alpha system

Use the SHOW CONFIG console command to find the LAN address of
additional adapters.

A VAX system

Use the following method to find the LAN address of additional adapters:

On Alpha systems, availability can be increased by using multiple LAN
adapters for booting because access to the MOP server and disk server
can occur via different LAN adapters. To use multiple adapter booting,
perform the steps in the following table.

Step

Task

1

Obtain the physical addresses of the additional LAN adapters.

2

Use these addresses to update the node definition in the DECnet or
LANCP database on some of the MOP servers so that they recognize the
satellite (described in Section 9.4.4).

3

If the satellite is already defined in the DECnet database, skip to
step 4. If the satellite is not defined in the DECnet database, specify
the SYS$SYSTEM:APB.EXE downline load file in the Alpha network database
(see Example 10-2).

4

Specify multiple LAN adapters on the boot command line. (Use the SHOW
DEVICE or SHOW CONFIG console command to obtain the names of adapters.)

The following command line is the same as that used for booting from a
single LAN adapter on an Alpha system (see Section 9.4.2) except that
it lists two LAN adapters, eza0 and ezb0, as the devices from which to
boot:

>>> b -flags 0,1 eza0, ezb0

In this command line:

Stage

What Happens

1

MOP booting is attempted from the first device (eza0). If that fails,
MOP booting is attempted from the next device (ezb0). When booting from
network devices, if the MOP boot attempt fails from all devices, then
the console starts again from the first device.

2

Once the MOP load has completed, the boot driver starts the NISCA
protocol on all of the LAN adapters. The NISCA protocol is used to
access the system disk server and finish loading the operating system
(see Appendix F).

OpenVMS supports only one hardware address attribute per remote node
definition in either a DECnet or LANCP database. To enable a satellite
with multiple LAN adapters to use any LAN adapter to boot into the
cluster, two different methods are available:

Define a pseudonode for each additional LAN adapter.

Create and maintain different node databases for different boot
nodes.

When creating different DECnet or LANCP databases on different boot
nodes:

Set up the databases so that a system booting from one LAN adapter
receives responses from a subset of the MOP servers. The same system
booting from a different LAN adapter receives responses from a
different subset of the MOP servers.

In each database, list a different LAN address for the same node
definition.

The procedures are similar for DECnet and LANCP, but the database file
names, utilities, and commands differ. For the DECnet procedure, see
Table 9-6. For the LANCP procedure, see Table 9-7.

Define the logical name NETNODE_REMOTE to different values on different
nodes so that it points to different files.

The logical NETNODE_REMOTE points to the working copy of the remote
node file you are creating.

2

Locate NETNODE_REMOTE.DAT files in the system-specific area for each
node.

On each of the various boot servers, ensure that the hardware
address is defined as a unique address that matches one of the adapters
on the satellite. Enter the following commands at the NCP command
prompt:

A NETNODE_REMOTE.DAT file located in [SYS0.SYSEXE] overrides one
located in [SYS0.SYSCOMMON.SYSEXE] for a system booting from system
root 0.

If the NETNODE_REMOTE.DAT files are copies of each other, the node
name, tertiary loader (for VAX) or LOAD FILE (for Alpha), load assist
agent, and load assist parameter are already set up. You need only
specify the new hardware address.

Because the default hardware address is stored in NETUPDATE.COM,
you must also edit this file on the second boot server.

Define the logical name LAN$NODE_DATABASE to different values on
different nodes so that it points to different files.

The logical LAN$NODE_DATABASE points to the working copy of the remote
node file you are creating.

2

Locate LAN$NODE_DATABASE.DAT files in the system-specific area for each
node.

On each of the various boot servers, ensure that the hardware
address is defined as a unique address that matches one of the adapters
on the satellite. Enter the following commands at the LANCP command
prompt:

If the LAN$NODE_DATABASE.DAT files are copies of each other, the node
name and the FILE and ROOT qualifier values are already set up. You
need only specify the new address.

++Alpha specific

Once the satellite receives the MOP downline load from the MOP server,
the satellite uses the booting LAN adapter to connect to any node
serving the system disk. The satellite continues to use the LAN
adapters on the boot command line exclusively until after the run-time
drivers are loaded. The satellite then switches to using the run-time
drivers and starts the local area OpenVMS Cluster protocol on all of
the LAN adapters.

For additional information about the NCP command syntax, refer to
DECnet for OpenVMS Network Management Utilities.

For DECnet--Plus: On an OpenVMS Cluster running
DECnet--Plus, you do not need to take the same actions in order to
support a satellite with more than one LAN adapter. The DECnet--Plus
support to downline load a satellite allows for an entry in the
database that contains a list of LAN adapter addresses. See the
DECnet--Plus documentation for complete information.

To control the number of workstations starting up simulataneously, use
DECbootsync, which is available through the NSIS Reusable Software
library:
http://eadc.aeo.dec.com/
. DECbootsync uses the distributed lock manager to control the number
of satellites allowed to continue their startup command procedures at
the same time.

DECbootsync does not control booting of the OpenVMS operating system,
but controls the execution of startup command procedures and
installation of layered products on satellites.

Disable MOP service on MOP servers temporarily

Until the MOP server can complete its own startup operations, boot
requests can be temporarily disabled by setting the DECnet Ethernet
circuit to a "Service Disabled" state as shown:

1

To disable MOP service during startup of a MOP server, enter the
following commands:

To reenable MOP service later, enter the following commands in a
command procedure so that they execute quickly and so that DECnet
service to the users is not disrupted:

$ MCR NCP
NCP> SET CIRCUIT MNA-1 STATE OFF
NCP> SET CIRCUIT MNA-1 SERVICE ENABLED
NCP> SET CIRCUIT MNA-1 STATE ON

This method prevents the MOP server from servicing the satellites; it
does not prevent the satellites from requesting a boot from other MOP
servers.

If a satellite that is requesting a boot receives no response, it
will make fewer boot requests over time. Thus, booting the satellite
may take longer than normal once MOP service is reenabled.

MNA-1 represents the MOP service circuit.

After entering these commands, service will be disabled in the
volatile database. Do not disable service permanently.

Reenable service as shown.

Disable MOP service for individual satellites

You can disable requests temporarily on a per-node basis in order to
clear a node's information from the DECnet database. Clear a node's
information from DECnet database on the MOP server using NCP, then
reenable nodes as desired to control booting:

1

To disable MOP service for a given node, enter the following command:

$ MCR NCP
NCP> CLEAR NODE
satellite HARDWARE ADDRESS

2

To reenable MOP service for that node, enter the following command:

$ MCR NCP
NCP> SET NODE
satellite ALL

This method does not prevent satellites from requesting boot service
from another MOP server.

After entering the commands, service will be disabled in the
volatile database. Do not disable service permanently.

Reenable service as shown.

Bring satellites to console prompt on shutdown

Use any of the following methods to halt a satellite so that it halts
(rather than reboots) upon restoration of power.

1

Use the VAXcluster Console System (VCS).

2

Stop in console mode upon Halt or powerup:

For Alpha computers:

>>> (SET AUTO_ACTION HALT)

For VAX 3100 or VAX 4000 series computers:

>>> (SET HALT 3)

For VAX 2000 series computers:

>>> TEST 53
2 ? >>> 3

3

Set up a satellite so that it will stop in console mode when a HALT
instruction is executed according to the instructions in the following
list.

Enter the following NCP commands so that a reboot will load an
image that does a HALT instruction:

When you want to allow the satellite to boot normally, enter the
following NCP commands so that OpenVMS will be loaded later:

$ MCR NCP
NCP> SET NODE
satellite ALL

If you plan to use the DECnet Trigger operation, it is important to use
a program to perform a HALT instruction that causes the satellite to
enter console mode. This is because systems that support remote
triggering only support it while the system is in console mode.

Some, but not all, satellites can be set up so they halt upon
restoration of power or execution of a HALT instruction rather than
automatically rebooting.

Note: You need to enter the SET commands only once on
each system because the settings are saved in nonvolatile RAM.

The READ_ADDR.SYS program, which is normally used to find out the
Ethernet address of a satellite node, also executes a HALT instruction
upon its completion.

Boot satellites remotely with Trigger

The console firmware in some satellites, such as the VAX 3100 and VAX
4000, allow you to boot them remotely using the DECnet Trigger
operation. You must turn on this capability at the console prompt
before you enter the NCP command TRIGGER, as shown:

1

To boot VAX satellites using the DECnet Trigger facility, enter these
commands at the console prompt:

>>> SET MOP 1
>>> SET TRIGGER 1
>>> SET PSWD

2

Trigger a satellite boot remotely by entering the following commands at
the NCP prompt, as follows:

Optionally, you can set up the MOP server to run a command procedure
and trigger 5 or 10 satellites at a time to stagger the boot-time work
load. You can boot satellites in a priority order, for example, first
boot your satellite, then high-priority satellites, and so on.

The SET TRIGGER 1 command enables the DECnet MOP listener, and the
SET PSWD command enables remote triggering. The SET PSWD command
prompts you twice for a 16-digit hexadecimal password string that is
used to validate a remote trigger request.

Note: You need to enter the SET commands only once on
each system, because the settings are saved in nonvolatile RAM.

MNA-1 represents the MOP service circuit, and
password is the hexadecimal number that you specified in step
1 with the SET PSWD command.

Important: When the SET HALT command is set up as
described in Table 9-8, a power failure will cause the satellite to
stop at the console prompt instead of automatically rebooting when
power is restored. This is appropriate for a mass power failure, but if
someone trips over the power cord for a single satellite it can result
in unnecessary unavailability.

You can provide a way to scan and trigger a reboot of satellites that
go down this way by simply running a batch job periodically that
performs the following tasks:

Uses the DCL lexical function F$GETSYI to check each node that
should be in the cluster.

Checks the CLUSTER_MEMBER lexical item.

Issues an NCP TRIGGER command for any satellite that is not
currently a member of the cluster.