Document revision date: 19 July 1999

This chapter describes the requirements and procedures for creating an OpenVMS Galaxy computing environment on an AlphaServer 4100.

8.1 Before You Start

Be sure to read the Release Notes chapter in this guide.

To create an OpenVMS Galaxy on an AlphaServer 4100, you must also be familiar with the following configuration and hardware requirements:

Two-instance maximum

You can run a maximum of two instances of OpenVMS on an AlphaServer 4100.

Console firmware

You must have AlphaServer 4100 console firmware that is on the Alpha Systems Firmware Update Version 5.4 CD-ROM that is included in the OpenVMS Version 7.2--1 CD-ROM package. Be sure to read the release notes that are included in the package before installing the firmware.

Console commands

In addition to the console hints in Chapter 6, you should be aware of the following:

• Enter console commands on one instance at a time.
• Do not enter console commands at another console until the command entered at the first console has completed.

AlphaServer 4100 clock

An AlphaServer 4100 has one clock. For an OpenVMS Galaxy, this means that you cannot run the two instances at different times. Also, the SET TIME command affects both instances. Note that this may not become evident until a number of hours have passed.

Console ports

COM1 (upper) is the console port for instance 0.
COM2 (lower) is the console port for instance 1.

Unlike creating an OpenVMS Galaxy on an AlphaServer 8400, you do not need additional hardware for the second console. COM-2 is used for this purpose.

CPUs

CPU0 must be the primary for instance 0.
CPU1 must be the primary for instance 1.
CPUs 2 and 3 are optional secondary CPUs that can be migrated.

I/O adapters

The four lower PCI slots belong to IOD0, which is the I/O adapter for instance 0.
The four upper PCI slots belong to IOD1, which is the I/O adapter for instance 1.

Storage controllers

You will need two storage controllers, such as KZPSAs. These can go to separate Storageworks boxes or to the same box for running as a SCSI cluster. One controller each goes in IOD0 and IOD1.

Network cards

If each instance needs network access, a network card (such as a DE500) is required for each instance.

One card each goes in IOD0 and IOD1.

Physical memory

Because OpenVMS Galaxy on an AlphaServer 4100 does not support memory holes, physical memory for an OpenVMS Galaxy environment must be contiguous. To achieve this on an AlphaServer 4100, one of the following must be true:

• All memory modules must be the same size (for example, 1GB).
• If two sizes are present, only one module can be a smaller size. You must put the larger modules into the lower numbered slots.

To create an OpenVMS Galaxy on an AlphaServer 4100 system, perform the steps in the following sections.

8.2 Step 1: Confirm the AlphaServer 4100 Configuration

Use the SHOW CONFIG command to make sure that the AlphaServer 4100 you are using to create an OpenVMS Galaxy environment meets the requirements described in Section 8.1.

At the console prompt, enter the following command:

P00>>>show config

The console displays the following information:

Console G53_75 OpenVMS PALcode V1.19-16, Digital UNIX PALcode V1.21-24 Module Type Rev Name System Motherboard 0 0000 mthrbrd0 Memory 512 MB EDO 0 0000 mem0 Memory 256 MB EDO 0 0000 mem1 CPU (Uncached) 0 0000 cpu0 CPU (Uncached) 0 0000 cpu1 Bridge (IOD0/IOD1) 600 0021 iod0/iod1 PCI Motherboard 8 0000 saddle0 CPU (Uncached) 0 0000 cpu2 CPU (Uncached) 0 0001 cpu3 Bus 0 iod0 (PCI0) Slot Option Name Type Rev Name 1 PCEB 4828086 0005 pceb0 4 DEC KZPSA 81011 0000 pks1 5 DECchip 21040-AA 21011 0023 tulip1 Bus 1 pceb0 (EISA Bridge connected to iod0, slot 1) Slot Option Name Type Rev Name Bus 0 iod1 (PCI1) Slot Option Name Type Rev Name 1 NCR 53C810 11000 0002 ncr0 2 DECchip 21040-AA 21011 0024 tulip0 3 DEC KZPSA 81011 0000 pks0

8.3 Step 2: Install OpenVMS Alpha Version 7.2--1

No special installation procedures are required to run OpenVMS Galaxy software. Galaxy functionality is included in the base operating system and can be enabled or disabled using the console command and system parameter values described later in this chapter.

If your AlphaServer 4100 is not part of a SCSI cluster, you must install OpenVMS Version 7.2--1 on two system disks---one disk for each instance.

If your AlphaServer 4100 is part of a SCSI cluster with a cluster-common system disk, install OpenVMS Version 7.2 on one system disk.

For more information about installing the OpenVMS Alpha operating system, see the OpenVMS Alpha Version 7.2 Upgrade and Installation Guide.

8.4 Step 3: Upgrade the Firmware

To upgrade the firmware, use the Alpha Systems Firmware Update Version 5.4 CD-ROM that is included in the OpenVMS Version 7.2--1 CD-ROM package. Be sure to read the release notes that are included in the package before installing the firmware.

8.5 Step 4: Set Environment Variables

Configure the primary console for instance 0.

CPU0 is the primary for instance 0.

Create the Galaxy environment variables. For descriptions of the Galaxy environment variables and common values for them, refer to Chapter 6.

The following example is for an AlphaServer 4100 with three CPUs and 512MB of memory divided into 256MB + 192MB + 64MB.

P00>>> create -nv lp_count 2 P00>>> create -nv lp_cpu_mask0 1 P00>>> create -nv lp_cpu_mask1 6 P00>>> create -nv lp_io_mask0 10 P00>>> create -nv lp_io_mask1 20 P00>>> create -nv lp_mem_size0 10000000 P00>>> create -nv lp_mem_size1 c000000 P00>>> create -nv lp_shared_mem_size 4000000 P00>>> set auto_action halt

If you have four CPUs and you want to assign all secondary CPUs to instance 1, the lp_cpu_mask1 variable will be E. If you split the CPUs between both instances, CPU 0 must be the primary for instance 0, and CPU 1 must be the primary CPU for instance 1.

The mem_size variables depend on your configuration and how you want to split it up.

• galaxy_io_mask0 must be set to 10
• galaxy_io_mask1 must be set to 20

You must set the console environment variable AUTO_ACTION to HALT. This will ensure that the system does not boot and that you will be able to enter the Galaxy command.

8.6 Step 5: Initialize the System and Start the Console Devices

1. Initialize the system and start the Galaxy firmware by entering the following commands:

   P00>>> init P00>>> galaxy

   
   After the self-test completes, the Galaxy command will start the console on instance 1.
   The first time that the Galaxy starts, it might display several messages like the following:

   CPU0 would not join

   IOD0 and IOD1 did not pass the power-up self-test

   
   This happens because there are two sets of environment variables, and the galaxy variables are not present initially on instance 1.
   Note that when the I/O bus is divided between the two Galaxy partitions, the port letter of a device might change. For example, a disk designated as DKC300 when the AlphaServer 4100 is a single system could become DKA300 when it is configured as partition 0 of the OpenVMS Galaxy.

2. Configure the console for instance 1.
   Use the same commands from step 2 to create the same Galaxy environment variables.

   P01>>> create -nv lp_cpu_mask0 1 P01>>> create -nv lp_cpu_mask1 6 P01>>> create -nv lp_io_mask0 10 P01>>> create -nv lp_io_mask1 20 P01>>> create -nv lp_mem_size0 10000000 P01>>> create -nv lp_mem_size1 c000000 P01>>> create -nv lp_count 2 P01>>> create -nv lp_shared_mem_size 4000000 P01>>> set auto_action halt

3. Initialize the system and restart the Galaxy firmware by entering the following command:

   P00>>> init

   
   When the console displays the following confirmation prompt, type Y:

   Do you REALLY want to reset the Galaxy (Y/N)

4. Configure the system root, boot device, and other related variables.
   The following example settings are from an OpenVMS Engineering system. Change these variables to meet the needs of your own environment.

   P00>>> set boot_osflags 12,0 P00>>> set bootdef_dev dka0 P00>>> set boot_reset off !!! must be OFF !!! P00>>> set ewa0_mode twisted P01>>> set boot_osflags 11,0 P01>>> set bootdef_dev dkb200 P01>>> set boot_reset off !!! must be OFF !!! P01>>> set ewa0_mode twisted

5. Boot instance 1 as follows:

   P01>>> boot

   
   Once instance 1 is booted, log in to the system account and edit the SYS$SYSTEM:MODPARAMS.DAT file to include the following line:

   GALAXY=1

   
   Confirm that the lines for the SCS node and SCS system ID are correct. Run AUTOGEN as follows to configure instance 1 as a Galaxy member, and leave the system halted:

   $ @SYS$UPDATE:AUTOGEN GETDATA SHUTDOWN INITIAL

6. Boot instance 0 as follows:

   P00>>> boot

   
   Once instance 0 is booted, log in to the system account and edit the SYS$SYSTEM:MODPARAMS.DAT file to include the following line:

   Add the line GALAXY=1

   
   Confirm that the lines for the SCS node and SCS system ID are correct. Run AUTOGEN as follows to configure instance 0 as a Galaxy member, and leave the system halted:

   $ @SYS$UPDATE:AUTOGEN GETDATA SHUTDOWN INITIAL

7. Prepare the Galaxy to come up automatically upon initialization or power cycle of the system. Set the AUTO_ACTION environment variable on both instances to RESTART.

   P00>>> set auto_action restart P01>>> set auto_action restart

8. Initialize the Galaxy again by entering the following commands at the primary console:

   P00>>> init

   
   When the console displays the following confirmation prompt, type Y:

   Do you REALLY want to reset the Galaxy (Y/N)

   
   Alternatively, you could power-cycle your system, and the Galaxy with both instances should bootstrap automatically.

Congratulations! You have created an OpenVMS Galaxy.

With OpenVMS Alpha Version 7.2--1, you can run a single-instance Galaxy on any Alpha platform. This capability allows early adopters to evaluate OpenVMS Galaxy features and, most important, to develop and test Galaxy-aware applications without incurring the expense of setting up a full-scale Galaxy computing environment on a system capable of running multiple instances of OpenVMS (for example, an AlphaServer 8400).

A single-instance Galaxy running on any Alpha system is not an emulator. It is OpenVMS Galaxy code with Galaxy interfaces and underlying operating system functions. All Galaxy APIs are present in a single-instance Galaxy (for example, resource management, shared memory access, event notification, locking for synchronization, and shared memory for global sections).

Any application that is run on a single-instance Galaxy will exercise the identical operating system code on a multiple-instance Galaxy system. This is accomplished by creating the configuration file SYS$SYSTEM:GLX$GCT.BIN, which OpenVMS reads into memory. On a Galaxy platform (for example, an AlphaServer 8400), the console places configuration data in memory for OpenVMS to use. Once the configuration data is in memory, regardless of its origin, OpenVMS boots as a Galaxy instance.

To use the Galaxy Configuration Utility (GCU) to create a single-instance Galaxy on any Alpha system, use the following procedure:

Run the GCU on the OpenVMS Alpha system on which you want to use the single-instance Galaxy.

If the GCU is run on a non-Galaxy system, it will prompt as to whether you want to create a single-instance Galaxy. Click on OK.

The GCU next prompts for the amount of memory to designate as shared memory. Enter any value that is a multiple of 8MB. Note that you must specify at least 8MB of shared memory if you want to boot as a Galaxy instance.

When the GCU has displayed the configuration, it will already have written the file GLX$GCT.BIN to the current directory. You can exit the GCU at this point. If you made a mistake or want to alter the configuration, you can close the current model and repeat the process.

To reboot the system as a Galaxy instance:

1. Copy the GLX$GCT.BIN file to SYS$SYSROOT:[SYSEXE]GLX$GCT.BIN.
2. Shut down the system.
3. Reboot with a conversational boot command (>>> B -FL 0,1 device).
4. SYSBOOT> SET GALAXY 1
5. SYSBOOT> CONTINUE
6. Add GALAXY=1 to SYS$SYSTEM:MODPARAMS.DAT

This chapter contains operating hints that OpenVMS Engineering has found useful for dealing with known issues and in creating and supporting OpenVMS Galaxy environments. These operating hints resolve issues that fall into the following categories:

• Hardware and firmware issues affecting all platforms
• Hardware and firmware issues affecting AlphaServer 8400 and 8200 systems
• Hardware and firmware issues affecting AlphaServer 4100 systems
• OpenVMS software issues that affect all platforms

The following sections describe known OpenVMS Galaxy issues that affect AlphaServer 8400, 8200, and 4100 platforms.

10.1.1 Console Tips

Because AlphaServer GS140, GS60, GS60E, 8400, 8200, and 4100 systems were designed prior to the Galaxy Software Architecture, OpenVMS Galaxy console firmware and system operations must handle a few restrictions.

The following list briefly describes some things you should be aware of and some things you should avoid doing:

• Do not set the BOOT_RESET environment variable to 1. This causes each secondary console to reset the bus before booting, thus resetting all previously booted partitions. Remember that OpenVMS Galaxy partitions share the hardware.
• Be patient. Console initialization and system rebooting can take several minutes.
• Do not attempt to abort a firmware update process!
  This can leave your system seriously hung.
• When updating console firmware, update ALL CPUs at the same time.
  You cannot run two different types of CPUs or two different firmware revisions. If you fail to provide consistent firmware revisions, the system will hang on power-up.
• Never issue the GALAXY command from a secondary console. This will reinitialize the system, and you will need to start over from the primary console.

Upon system power-up, if the AUTO_ACTION console environment variable is set to BOOT or RESTART for instance 0 and the LP_COUNT environment variable is set to 2 or more, then the GALAXY command will automatically be issued and instance 0 will attempt to boot.

The setting of AUTO_ACTION in the console environment variables for the other instances will dictate their behavior upon the issuing of the GALAXY command (whether it is issued automatically or by the user from the console).

To set up your system for this feature, you must set the console environment variable "AUTO_ACTION" to "RESTART" or "BOOT" on each instance, and be sure to specify appropriate values for the BOOT_OSFLAGS and BOOTDEF_DEV environment variables for each instance.

10.1.3 Disparate Environment Variables

Be careful when setting Galaxy environment variables at secondary consoles.

It is very easy to cause problems in a Galaxy configuration by setting the Galaxy (lp*) console environment variables differently on the main console from the consoles of additional instances.

If you boot a secondary instance of a Galaxy system with the LP_COUNT console environment variable set to zero, OpenVMS will hang after the banner is displayed. Additionally, on an AlphaServer 4100 Galaxy system, the system will display an EISA configuration error; if the primary instance is already booted with the LP_COUNT environment variable set to two, it then crashes with a machine check.

OpenVMS Engineering expects to change these rules in a future release. For now, you must manually set all the environment variables to be the same in all instances and then INIT.

10.1.4 Console INIT Command Is Not Per-Instance

You cannot use the INIT command to reset a single instance. The console INIT command affects the entire system (not individual instances) by sending a reset signal to buses and devices.

You can enter an INIT command at any console, but the output is displayed at the primary console.

When you enter the INIT command, the console displays the following question:

"Do you really want to reset ALL partitions? (Y/N)"

10.1.5 INIT Command Behavior

The INIT command and power-on will both start secondary consoles if the LP_COUNT console environment variable and the AUTO_ACTION console environment variable are set appropriately on a primary instance.

Secondary instances will then boot depending on the setting of their AUTO_ACTION variable, as shown in Table 10-1.

When the LP_COUNT console environment variable is set to 0 or the AUTO_ACTION console environment variable is set to HALT, the LPINIT is not done by either the power-on or INIT.

Table 10-1 shows the effect of INIT or power cycle when the LP_COUNT console environment variable is set to a nonzero value.

Table 10-1 Effect of INIT or Power Cycle

	AUTO_ACTION Setting on Primary Console
Effect on	Halt	Restart or Boot
Secondary consoles	Not started	Started
Primary instance	Not booted	Booted 1
Secondary instance	Not booted	Booted depending on AUTO_ACTION setting on secondary console

If INIT is issued at a secondary console, that secondary console is the one that does not boot. Others (including the primary console) will boot depending on the AUTO_ACTION setting for that instance.

10.1.6 CTRL/P Issues

CTRL/P affects only one instance. If an instance is in an IPL31 loop, CTRL/P might not work.

Avoid using CTRL/P during SYSBOOT and Bugcheck. If you enter CTRL/P duing SYSBOOT followed by a BOOT command, the console might respond with the following message:

Inconsistent boot driver state. System is configured with multiple partitions. A complete INIT must be performed before rebooting.

10.1.7 CPUs That Cannot Be Reassigned

When CPUs cannot be reassigned with the Galaxy Configuration Utility (GCU), this usually means that no communications exist between instances.

For CPUs to be reassigned, instances must be in a cluster or DECnet must be set up with proxies. Note that TCP/IP communications between instances are being developed for a future release.

10.1.8 GLXCRASH is the Heartbeat Timeout BUGCHECK

Each SHARING member in an OpenVMS Galaxy ticks a heartbeat cell in shared memory that other instances watch. If an instance's heartbeat stops ticking for the amount of time specified as milliseconds in the GLX_INST_TMO SYSGEN parameter, that instance will be assumed to be "dead" and will be removed as a sharing member.

If you CTRL/P a sharing member for longer than GLX_INST_TMO milliseconds, upon issuing a CONTINUE command from the console, the instance will immediately bugcheck with a GLXCRASH bugcheck. For example:

^P and wait a while, then P00>>>c continuing CPU 0 **** OpenVMS (TM) Alpha Operating System X6PI-SSB - BUGCHECK **** ** Bugcheck code = 00000A94: GLXCRASH, BUGCHK requested from another Galaxy instance

This is very similar to the behavior of an OpenVMS Cluster that would result in a CLUEXIT bugcheck if a cluster member was in a CTRL/P state for longer than RECNXINTERVAL seconds.

Sharing members all use the same value of GLX_INST_TMO. The default value is currently 5000 milliseconds. To debug or test, you can increase the timeout value by resetting the GLX_INST_TMO SYSGEN parameter.

	privacy and legal statement
6512PRO_004.HTML