HP OpenVMS Systems Documentation

Content starts here

OpenVMS Alpha Partitioning and Galaxy Guide

Previous Contents Index

3.6 System Dump Analyzer (SDA) Support for RADs

The following System Dump Analyzer (SDA) commands have been enhanced to include RAD support.

  • SHOW RMD (reserved memory descriptor)

3.6.1 SHOW RAD

The SDA command SHOW RAD displays:

  • Settings and explanations of the RAD_SUPPORT system parameter fields
  • Assignment of CPUs and memory to the RADs

This command is useful only on hardware platforms that support RADs (for example, AlphaServer GS160 systems). By default, the SHOW RAD command displays the settings of the RAD_SUPPORT system parameter fields.


SHOW RAD [number|/ALL]



Displays information on CPUs and memory for the specified RAD.



Displays settings of the RAD_SUPPORT parameter fields and all CPU/memory assignments.

3.6.2 SHOW RAD Examples

Example 1 shows the settings of the RAD_SUPPORT system parameter fields.


    Resource Affinity Domains

    RAD information header address: FFFFFFFF.82C2F940
    Maximum RAD count:                       00000008
    RAD containing SYS$BASE_IMAGE:           00000000
    RAD support flags:                       0000000F

    3         2 2         1 1
    1         4 3         6 5         8 7         0
    |..|..| skip|ss|gg|ww|pp|..|..|..|..|..|fs|cr|ae|
    |..|..|    0| 0| 0| 0| 0|..|..|..|..|..|00|11|11|

    Bit 0 = 1:          RAD support is enabled

    Bit 1 = 1:          Soft RAD affinity support is enabled
                        (Default scheduler skip count of 16 attempts)

    Bit 2 = 1:          System-space replication support is enabled

    Bit 3 = 1:          Copy on soft fault is enabled

    Bit 4 = 0:          Default RAD-based page allocation in use

                        Allocation Type               RAD choice
                        ---------------               ----------
                        Process-private pagefault     Home
                        Process creation or inswap    Random
                        Global pagefault              Random
                        System-space page allocation  Current

    Bit 5 = 0:          RAD debug feature is disabled)

Example 2 shows information about the CPUs and memory for RAD 2.


    Resource Affinity Domain 0002

    CPU sets:

      Active      08 09 10 11
      Configure   08 09 10 11
      Potential   08 09 10 11

    PFN ranges:

      Start PFN   End PFN     PFN count   Flags
      ---------   --------    ---------   -----
      01000000    0101FFFF    00020000    000A  OpenVMS Base
      01020000    0103FFFF    00020000    0010  Galaxy_Shared

    SYSPTBR:      01003C00)

3.6.3 SHOW RMD (Reserved Memory Descriptor)

The SDA command SHOW RMD has been enhanced to indicate the RAD from which reserved memory has been allocated. If a RAD was not specified when the reserved memory was allocated, then SDA displays ANY.

3.6.4 SHOW PFD

The SDA command SHOW PFD has been enhanced to include the /RAD qualifier. It is analogous to the existing /COLOR qualifier.

3.6.5 RAD Support for Hard Affinity


On a system that supports RADs, the set of CPUs to which you affinitize a process should be in the same RAD. For example, on an AlphaServer GS160 with CPUs 0,1,2,3 in RAD 0 and with CPUs 4,5,6,7 in RAD 1, SET=2,3,4,5 would not be a good choice because half of the time you could be executing off your home RAD.

Chapter 4
Creating an OpenVMS Galaxy on AlphaServer GS140/GS60/GS60E Systems

OpenVMS Alpha Version 7.3 provides support for OpenVMS Galaxy configurations on AlphaServer GS60, GS60E, and GS140 systems. You can run three instances of OpenVMS on AlphaServer GS140 systems or two instances on AlphaServer GS60/GS60E systems.

To create OpenVMS Galaxy environments on AlphaServer GS60, GS60E, and GS140 systems, you must download the latest version of the V5.4-xx console firmware from the following location:


When you have the firmware, you can:

  • Create an OpenVMS Galaxy computing environment on an AlphaServer GS140 by following the procedures in Chapter 5.
  • Create an OpenVMS Galaxy computing environment on AlphaServer GS60 or GS60E systems by following the procedures in Chapter 6.

Chapter 5
Creating an OpenVMS Galaxy on an AlphaServer 8400 System

This chapter describes how to create an OpenVMS Galaxy computing environment on an AlphaServer 8400.

5.1 Step 1: Choose a Configuration and Determine Hardware Requirements

Quick Summary of an AlphaServer 8400 Galaxy Configuration

9 slots for:

I/O modules (of type KFTIA or KFTHA)
Memory modules
Processor modules (2 CPUs per module)

Console line for each partition:

Standard UART for first partition
KFE72-DA for each additional partition


Must have an I/O module per partition.
Maximum of 3 I/O modules.
Must have at least one CPU module per partition.

Example Configuration 1

2 partitions, 8 CPUs, 12 GB memory

9 slots allocated as follows:
2 I/O modules
4 Processor modules (2 CPUs each)
3 Memory modules (4 GB each)

Example Configuration 2

3 partitions, 8 CPUs, 8 GB memory

9 slots allocated as follows:
3 I/O modules
4 Processor modules (2 CPUs each)
2 Memory modules (4 GB each)

5.2 Step 2: Set Up Hardware

When you have acquired the necessary hardware for your configuration, follow the procedures in this section to assemble it.

5.2.1 Overview of KFE72-DA Console Subsystem Hardware

The AlphaServer 8400 provides a standard built-in UART, which is used as the console line for the primary Galaxy instance. The console for each additional instance requires a KFE72-DA console subsystem, which is the set of EISA-bus modules that establishes an additional console port.

Note that the AlphaServer 8400 supports a maximum of three I/O modules. Attempting to configure more than three is unsupported.

Each separate KFE72-DA subsystem must be installed in a separate DWLPB card cage with a hose connecting it to a separate I/O module of type KFTIA or KFTHA.

All KFTIA I/O modules must be installed first, starting at slot 8. Any KFTHA I/O modules must follow the KFTIA modules, using the consecutively lower-numbered slots.

You can use any combination of these two I/O modules as long as you follow this slot assignment rule.

When configuring a console subsystem, the I/O hose connecting the I/O module and DWLPB card cage must be plugged into the lowest hose port. Not just the lowest available hose port, but the absolute first hose port; the one closest to the top of the module.

The KFE72-DA contains three EISA modules that provide:

  • Two COM ports
  • An Ethernet port
  • A small speaker and other ports (such as a keyboard and a mouse, which are not used for Galaxy configurations)

5.2.2 Installing the KFE72-DA Modules

For each instance of the OpenVMS operating system after instance zero, you must install the following three modules in the PCI card cage:

  • Standard I/O module
  • Serial port module
  • Connector module

To install these modules, follow the procedures in Section to Section, which supplement the installation procedures for KFE72-DA modules in Chapter 5 of the KFE72 Installation Guide. Slide the PCI Card Cage Out

Follow procedures in Section 5.2.1 in the KFE72 Installation Guide. Insert Modules and Connect Ribbon Cables


When installing PCI modules, be sure the option bulkheads mate with the EMI gasket on the PCI card cage.

KFE72-DA modules must occupy slots 0, 1, and 2 of the DWLPB card cage.

To insert the modules in the PCI card cages and connect the appropriate ribbon cables, refer to Figure 5-1 and perform the following steps:

Figure 5-1 Attaching Ribbon Cables

  1. Insert the standard I/O module (B2110-AA) in slot 0. Secure the module to the card cage with a screw.
  2. Attach the 60-pin ribbon cables (17-04116-01) on the serial port module (54-25082-01) at connectors J1 and J2.
  3. Insert the serial port module (54-25082-01) in slot 1. Secure the module to the card cage with a screw.
  4. Attach the 60-pin ribbon cable (17-04116-01) from the serial port module at connector J1 to the standard I/O module.
  5. Insert the connector module in slot 2.
  6. Attach the 34-pin ribbon cable (17-04115-01) between the standard I/O module (B2110-AA) in slot 0 and the connector module (54-25133-01) in slot 2.
  7. Attach the 60-pin ribbon cable (17-04116-01) from the serial port module at connector J2 to the connector module. Attaching Connectors

To connect the console terminal and additional devices, refer to Figure 5-2 and connect the console serial line (H8571-J connector) to COM1.

Note that the pair of arrows between the numbers 1 and 2 on the serial port module is an industry standard symbol for a serial port and does not indicate port numbers.

Figure 5-2 Connectors

5.2.3 Slide Shelf Back Into System

To return the card cage, follow steps 2 through 9 in the procedure in Section 5.2.3 of the KFE72 Installation Guide.

5.2.4 Using a Terminal Server

You may want to bring your console lines together using a terminal server. For example, use a DECserver200 to allow reverse-LAT access to each console over the network. While this is not strictly required, it greatly simplifies OpenVMS Galaxy configuration management. Refer to the appropriate product documentation for details about configuring a LAT Server or other terminal concentrator.

5.2.5 Installing EISA Devices

Plug-in EISA devices can only be configured in partition 0. After installing EISA devices, the console will issue a message requesting that you run the EISA Configuration Utility (ECU).

Run the ECU as follows:

  1. Shut down all OpenVMS Galaxy instances.
  2. Be sure your floppy disk drive is properly connected to the primary partitions hardware. Typically the drive can be cabled into the Connector Module ("Beeper" part number 54-25133-01) in PCI slot 2.
  3. Insert the diskette containing the ECU image.
  4. Issue the following commands from the primary console:

     P00>>> INITIALIZE
     P00>>> RUN ECU
  5. Follow the procedures outlined by the ECU and exit when done.
  6. P00>>> boot
  9. P00>>> INITIALIZE
  10. P00>>> LPINIT
  11. Reboot the OpenVMS Galaxy.

There are two versions of the ECU, one that runs on a graphics terminal and another that runs on character-cell terminals. Both versions are on the diskette, and the console determines which one to run. For OpenVMS Galaxy systems, the primary console will always be a serial device with a character cell terminal.

If the ECU is not run, OpenVMS will display the following message:

        %SYSTEM-I-NOCONFIGDATA, IRQ Configuration data for EISA
     slot xxx was not found, please run the ECU and reboot.

If you ignore this message, the system will boot, but the plug-in EISA devices will be ignored.

Once you have configured and set up the OpenVMS Galaxy hardware as described in the previous sections, perform the following steps to install and boot OpenVMS Galaxy instances.

5.3 Step 3: Create System Disk

Decide whether to use a system disk per instance or whether to use a cluster common disk.

A new SECURITY.EXE is required for all cluster members running a version prior to OpenVMS Version 7.1-2 that share the same VMS$OBJECTS.DAT file with Galaxy instances.

5.4 Step 4: Install OpenVMS Alpha Version 7.3

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.

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

5.4.1 OpenVMS Galaxy Licensing Information

See OpenVMS License Management Utility Manual.

5.5 Step 5: Upgrade the Firmware

Creating an OpenVMS Galaxy environment on an AlphaServer 8400 requires a firmware upgrade to each processor module. If you use these modules again in a non-Galaxy configuration, you will need to reinstall the previous firmware. It is a good practice to have a current firmware CD on hand.

It saves some time if you install ALL processor modules you intend to use and update them at the same time. The AlphaServer 8400 requires that you use the same firmware on all processor boards. If you need to upgrade a board at a later time, you must:

  1. Remove all boards that are not at the same firmware revision level.
  2. Update the older boards.
  3. Reinstall the remaining boards.

To upgrade your firmware, the system must be powered on, running in non-Galaxy mode (that is, the lp_count console environment variable---if you have established it---must be set to zero).

To set the console environment variable, use the following commands:

P00>>> INIT

To upgrade the firmware, use the standard console firmware update available from AlphaServers Engineering.

5.6 Step 6: Set Environment Variables

When you have upgraded the firmware on all of your processor modules, you can create the Galaxy-specific environment variables as shown in the following example. This example assumes you are configuring a 2-instance, 8 CPU, 1 GB OpenVMS Galaxy computing environment.

P00>>> create -nv lp_count         2
P00>>> create -nv lp_cpu_mask0     1
P00>>> create -nv lp_cpu_mask1     fe
P00>>> create -nv lp_io_mask0      100
P00>>> create -nv lp_io_mask1      80
P00>>> create -nv lp_mem_size0     10000000
P00>>> create -nv lp_mem_size1     10000000
P00>>> create -nv lp_shared_mem_size  20000000
P00>>> init

Once you create these variables, you can use console SET commands to manipulate them. These variables need only be created on processor 0.

The following descriptions give detailed information about each environment variable.


If set to zero, the system will boot a traditional SMP configuration only. Galaxy console mode is OFF.

If set to a nonzero value, the Galaxy features will be used, and the Galaxy variables will be interpreted. The exact value of LP_COUNT represents the number of Galaxy partitions the console should expect. Currently, this number must be 0, 2, or 3.

Note that if you assign resources for three partitions and set this variable to two, the remaining resources will be left unassigned. Unassigned CPUs will be assigned to partition 0. You may also create the variables for the maximum number of partitions ahead of time and simply not assign resources to them (set them to nonzero values) until needed.

LP_CPU_MASK partition number

This bit-mask determines which CPUs are to be initially assigned to the specified Galaxy partition number. The AlphaServer 8400 console chooses the first even-numbered CPU in a partition as its primary CPU, beginning with CPU 0 for the initial instance. Keep this in mind when assigning the resources. (In other words, do not assign only an odd-numbered CPU to a partition.)

LP_IO_MASK partition number

These variables assign I/O modules by slot number to each instance:

  • 100 represents the I/O module in slot 8.
  • 80 represents the I/O module in slot 7.
  • 40 represents the I/O module in slot 6.

These are the only valid assignments for the AlphaServer 8400.

You can assign more than one I/O module to an instance using these masks, but each Galaxy instance requires at least one I/O module.

LP_MEM_SIZE partition number

These variables allocate a specific amount of private memory for the specified instance. It is imperative that you create these variables using proper values for the amount of memory in your system and the desired assignments for each instance. Refer to Table B-1 for common values.

See also the shared memory variable on the following line.


This variable allocates memory for use as shared memory. Refer to Appendix B for common values.


Shared memory must be assigned in multiples of 8 MB and all values are expressed in hexadecimal bytes.

You can define only the amount of shared memory to use, and leave the other LP_MEM_SIZE variables undefined. This will cause the console to allocate the shared memory from the high address space, and to split the remaining memory equally among the number of partitions specified by the LP_COUNT variable. If you also explicitly assign memory to a specific partition using a LP_MEM_SIZE variable, but you leave other partition memory assignments undefined, the console will again assign the memory fragments for shared memory and any partitions with explicit assignments, and will then split and assign the remaining memory to any remaining partitions not having explicit memory assignments.


You should set these variables on each of your Galaxy consoles prior to booting to ensure that AUTOGEN reboots correctly when it needs to reboot the system after an initial installation and after a system failure or operator-requested reboot.

Galaxy Environment Variables Example

P00>>> SHOW LP*

lp_count 2
lp_shared_mem_size 20000000   (512 MB)
lp_mem_size0 10000000 (256 MB)
lp_mem_size1 10000000 (256 MB)
lp_cpu_mask0 1 (CPU 0)
lp_cpu_mask1 fe (CPUs 1-7)
lp_io_mask0 100 (I/O module in slot 8)
lp_io_mask1 80 (I/O module in slot 7)


5.7 Step 7: Start the Secondary Console Devices

If the KFE72-DA was ever configured for Windows NT, it probably expects to find the video board and will hang if one is not present. This is a common occurrence when configuring an OpenVMS Galaxy. A console command can be used to set the mode of operation as follows:


When you issue this command to the primary console prior to initializing the secondary consoles, the setting will be propagated to the secondary console hardware.

If you decide to use the Ethernet port, you may need to inform the console of which media type and connection you intend to use: AUI, UDP, or Twisted Pair. The console and operating system will determine which to use, but you can assign a specific media type using the following commands:



The first command displays a list of available network devices. The second command establishes the default media type for the specified device (EWA0 in this example). This should be done for all Ethernet devices prior to initializing the secondary consoles.

Once you have set your console mode and network media types (if used) you should reinitialize the system to ensure that the current settings are saved. If you have already defined your Galaxy partitions, you can initialize now. If you have not defined your Galaxy partitions, you should defer initialization until later.

If you are ready to initialize the system, enter:

P00>>> INIT

You should see the primary console respond with its usual power-up self-test (POST) report. This could take up to 2 minutes. If you have properly defined the Galaxy partitions, only the I/O devices associated with the primary partition will be visible.

To verify that partitioning has occurred, enter:




To initialize the secondary console, enter:


The console displays the following:

Partition 0: Primary CPU = 0
Partition 1: Primary CPU = 2
Partition 0: Memory Base = 000000000   Size = 010000000
Partition 1: Memory Base = 010000000   Size = 010000000
Shared Memory Base = 020000000   Size = 010000000
LP Configuration Tree = 12c000
starting cpu 1 in Partition 1 at address 01000c001
starting cpu 2 in Partition 1 at address 01000c001
starting cpu 3 in Partition 1 at address 01000c001
starting cpu 4 in Partition 1 at address 01000c001
starting cpu 5 in Partition 1 at address 01000c001
starting cpu 6 in Partition 1 at address 01000c001
starting cpu 7 in Partition 1 at address 01000c001


This command must be entered from the primary Galaxy console. If the Galaxy partitions have been properly defined, and hardware resources have been properly configured, you should see the primary console start the processors assigned to each secondary partition. Each of the secondary consoles should initialize within about 2 minutes.

If one or more consoles fails to initialize, you should double-check your hardware installation, Galaxy partition definitions, and hardware assignments.

For more information about OpenVMS console restrictions and hints, see Chapter 11.

Previous Next Contents Index