Updated: 11 December 1998

OpenVMS Alpha Galaxy Guide

When you have correctly installed the Galaxy firmware and configured the consoles, you can boot the initial Galaxy environment as follows:

For each Galaxy instance:

P00>>> B -FL 0,1 DKA100 // or whatever your boot device is. SYSBOOT> SET GALAXY 1 SYSBOOT> CONTINUE

Congratulations! You have created an OpenVMS Galaxy.

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

7.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 Version AS4_G53_75 (Available on the OpenVMS Alpha Version V7.2 kit).

Console commands

In addition to the console hints in Chapter 5, 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, 1 GB).
• 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 following steps:

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

2. Install OpenVMS Alpha Version 7.2.
   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 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.
3. To upgrade the firmware, use one of the following procedures:
   Copy the firmware file AS4_G53_75.SYS to MOM$SYSTEM on a MOP-enabled server that is accessible to the AlphaServer 4100. Enter the following commands on the console:

   P00>>> boot -fl 0,0 ewa0 -fi as4_g53_75 UPD> update srm* <power-cycle system>

   
   Or, use the following commands:

   P00>>> BOOT -FLAGS 0,80 cd_device_name . . . Bootfile: [GALAXY_FIRM_072.KIT]AS4_G53_75.EXE . . .

4. 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 5.
   The following example is for an AlphaServer 4100 with three CPUs and 512 MB of memory divided into 256 MB + 192 MB + 64 MB.

   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_count 2 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.
5. 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.

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

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

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

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

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

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

12. 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, 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 8 MB. Note that you must specify at least 8 MB 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 information that OpenVMS Engineering has found useful in creating and running OpenVMS Galaxy environments.

9.1 System Auto-Action

Upon system power-up, if the AUTO_ACTION console environment variable is set to BOOT or RESTART for instance 0, 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 comamnd (whether it is issued automatically or by the user from the console).

To setup 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.

9.2 Changing Console Environment variables

Once you have established the initial set of LP_* environment variables for OpenVMS Galaxy operation and booted your system, changing environment variable values requires that you first re-initialize the system, change the values, and re-initialize again. Wrapping the changes between INITs is required to properly propagate the new values to all partitions.

Because AlphaServer 8400 and 8200 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 re-initialize the system, and you will need to start over from the primary console.

The GLX_INST_TMO SYSGEN parameter:

Each SHARING member ticks a heartbeat cell in shared memory which the other instances watch. If an instance's heartbeat stops ticking for GLX_INST_TMO milliseconds, that instance will be assumed to be dead and removed as a sharing member.

If for example, you CTRL-P a sharing member for longer that GLX_INST_TMO milliseconds, upon issuing a Continue command from the console, the instance will immediately bugcheck with a GLXEXIT bugcheck. This is very similar to the behavior of an OpenVMScluster that would result in a CLUEXIT bugcheck if a cluster member was in a CTRL-P state for longer than RECNXINTERVAL seconds.

The sharing members all use the same value of GLX_INST_TMO. The value used is the smallest value of any node that has EVER booted into the Galaxy.

9.5 Turning Galaxy Mode Off

If you want to turn off OpenVMS Galaxy software, change the lp_count environment variable as follows and enter the following commands:

>>> SET LP_COUNT 0 ! Return to monolithic SMP config >>> INIT ! Return to single SMP console >>> B -fl 0,1 device ! Stop at SYSBOOT SYSBOOT> SET GALAXY 0 SYSBOOT> CONTINUE

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6512PRO_004.HTML