Document revision date: 15 July 2002

To boot a satellite, enter the following command:

>>> BOOT LAN-adapter-device-name

In the example, the LAN-adapter-device-name could be any valid LAN adapter name, for example EZA0 or XQB0.

If you need to perform a conversational boot, use the command shown in the following table.

IF the system is...	THEN...
An Alpha system	At the Alpha system console prompt (>>>), enter: >>> b -flags 0,1 eza0 In this example, -flags stands for the flags command line qualifier, which takes two values: System root number The "0" tells the console to boot from the system root [SYS0]. This is ignored when booting satellite nodes because the system root comes from the network database of the boot node. Conversational boot flag The "1" indicates that the boot should be conversational. The argument eza0 is the LAN adapter to be used for booting. Finally, notice that a load file is not specified in this boot command line. For satellite booting, the load file is part of the node description in the DECnet or LANCP database.
A VAX system	At the VAX system console prompt (>>>), specify the full device name in the boot command: >>>B/R5=1 XQB0 The exact syntax will vary depending on system type. Please refer to the hardware user's guide for your system.

If the boot fails:

• If the configuration permits and the network database is properly set up, reenter the boot command using another LAN adapter (see Section 9.4.4).
• See Section C.3.5 for information about troubleshooting satellite booting problems.

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: Enter the console command SHOW ETHERNET. Boot the READ_ADDR program using the following commands: >>>B/100 XQB0 Bootfile:READ_ADDR

9.4.3 Booting from Multiple LAN Adapters (Alpha Only)

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).

9.4.4 Enabling Satellites to Use Alternate LAN Adapters for Booting

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.

Defining Pseudonodes for Additional LAN Adapters

When defining a pseudonode with a different DECnet or LANCP address:

• Make sure the address points to the same cluster satellite root directory as the existing node definition (to associate the pseudonode with the satellite).
• Specify the hardware address of the alternate LAN adapter in the pseudonode definition.

For DECnet, follow the procedure shown in Table 9-4. For LANCP, follow the procedure shown in Table 9-5.

Table 9-4 Procedure for Defining a Pseudonode Using DECnet MOP Services

Step	Procedure	Comments
1	Display the node's existing definition using the following NCP command: $ RUN SYS$SYSTEM:NCP NCP> SHOW NODE node-name CHARACTERISTICS	This command displays a list of the satellite's characteristics, such as its hardware address, load assist agent, load assist parameter, and more.
2	Create a pseudonode by defining a unique DECnet address and node name at the NCP command prompt, as follows: ++DEFINE NODE pseudo-area.pseudo-number - NAME pseudo-node-name - LOAD FILE APB.EXE - LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE - LOAD ASSIST PARAMETER disk$sys:[< root.>] - HARDWARE ADDRESS xx-xx-xx-xx-xx-xx	This example is specific to an Alpha node. For a VAX node, replace the command LOAD FILE APB.EXE, with TERTIARY LOADER SYS$SYSTEM:TERTIARY_VMB.EXE.

Table 9-5 Procedure for Defining a Pseudonode Using LANCP MOP Services

Step	Procedure	Comments
1	Display the node's existing definition using the following LANCP command: $ RUN SYS$SYSTEM:LANCP LANCP> SHOW NODE node-name	This command displays a list of the satellite's characteristics, such as its hardware address and root directory address.
2	Create a pseudonode by defining a unique LANCP address and node name at the LANCP command prompt, as follows: ++DEFINE NODE pseudo-node-name - /FILE= APB.EXE - /ROOT= disk$sys:[< root.>] - /ADDRESS= xx-xx-xx-xx-xx-xx	This example is specific to an Alpha node. For a VAX node, replace the qualifier FILE=APB.EXE with FILE=NISCS_LOAD.EXE.

Creating 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.

Table 9-6 Procedure for Creating Different DECnet Node Databases

Step	Procedure	Comments
1	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: ++DEFINE NODE area.number - NAME node-name - LOAD FILE APB.EXE - LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE - LOAD ASSIST PARAMETER disk$sys:[< root.>] - HARDWARE ADDRESS xx-xx-xx-xx-xx-xx	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.

Table 9-7 Procedure for Creating Different LANCP Node Databases

Step	Procedure	Comments
1	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: ++DEFINE NODE node-name - /FILE= APB.EXE - /ROOT= disk$sys:[< root.>] - /ADDRESS= xx-xx-xx-xx-xx-xx	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.

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.

9.4.5 Configuring MOP Service

On a boot node, CLUSTER_CONFIG.COM enables the DECnet MOP downline load service on the first circuit that is found in the DECnet database.

On systems running DECnet for OpenVMS, display the circuit state and the service (MOP downline load service) state using the following command:

$ MCR NCP SHOW CHAR KNOWN CIRCUITS

. . . Circuit = SVA-0 State = on Service = enabled . . .

This example shows that circuit SVA-0 is in the ON state with the MOP downline service enabled. This is the correct state to support MOP downline loading for satellites.

Enabling MOP service on additional LAN adapters (circuits) must be performed manually. For example, enter the following NCP commands to enable service for the circuit QNA-1:

$ MCR NCP SET CIRCUIT QNA-1 STATE OFF $ MCR NCP SET CIRCUIT QNA-1 SERVICE ENABLED STATE ON $ MCR NCP DEFINE CIRCUIT QNA-1 SERVICE ENABLED

Reference: For more details, refer to DECnet-Plus for OpenVMS Network Management.

9.4.6 Controlling Satellite Booting

You can control the satellite boot process in a number of ways. Table 9-8 shows examples specific to DECnet for OpenVMS. Refer to the DECnet--Plus documentation for equivalent information.

Table 9-8 Controlling Satellite Booting

Method	Comments
Use DECbootsync
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: $ MCR NCP DEFINE CIRCUIT MNA-1 - _$ SERVICE DISABLED $ @SYS$MANAGER:STARTNET $ MCR NCP DEFINE CIRCUIT MNA-1 - _$ SERVICE ENABLED 2 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: $ MCR NCP NCP> CLEAR NODE node LOAD ASSIST PARAMETER NCP> CLEAR NODE node LOAD ASSIST AGENT NCP> SET NODE node LOAD FILE - _ MOM$LOAD:READ_ADDR.SYS Shut down the satellite, and specify an immediate reboot using the following SYSMAN command: $ MCR SYSMAN SYSMAN> SET ENVIRONMENT/NODE= satellite SYSMAN> DO @SYS$UPDATE:AUTOGEN REBOOT 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: $ MCR NCP NCP> TRIGGER NODE satellite - _ VIA MNA-1 SERVICE PASSWORD password
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:

1. Uses the DCL lexical function F$GETSYI to check each node that should be in the cluster.
2. Checks the CLUSTER_MEMBER lexical item.
3. Issues an NCP TRIGGER command for any satellite that is not currently a member of the cluster.

	privacy and legal statement
4477PRO_018.HTML