Updated: 11 December 1998

OpenVMS Alpha Galaxy Guide

The OpenVMS Galaxy Software Architecture on OpenVMS (OpenVMS Galaxy) is a system integrated product (SIP). That is, OpenVMS Galaxy code is integrated and delivered with the OpenVMS operating system.

The License Management Facility (LMF) Product Authorization Keys (PAKs) representing OpenVMS Galaxy licenses allow you to access and use OpenVMS Galaxy software. For more information about the location of the PAKs available with Open-VMS Alpha Version 7.2, see the Guide to OpenVMS Version 7.2 CD-ROMs.

4.1 OpenVMS Galaxy Licensing Requirements

The following list summarizes OpenVMS Galaxy licensing requirements:

• One OpenVMS Operating System License for a Galaxy system
• One SMP Extension License for each CPU after the first CPU
• One OpenVMS Galaxy License for each CPU in a Galaxy system
• No changes to how Compaq layered products are licensed:
  • One capacity license per system
  • One user license per use

The following sections describe these requirements in more detail.

4.1.1 OpenVMS Operating System License

When an AlphaServer system is configured as an OpenVMS Galaxy system, there are no changes in how a system is licensed for the OpenVMS operating system.

One OpenVMS Base License is required for the Galaxy system, plus one SMP Extension License for each CPU after the first CPU.

4.1.2 OpenVMS Galaxy License

In order to create and run multiple instances, one OpenVMS Galaxy License is required for each CPU in a Galaxy system.

License rights for running a single-instance Galaxy on any Alpha system are provided by the OpenVMS Base License.

4.1.3 OpenVMS Layered Products License

Compaq software layered products on OpenVMS Galaxy configurations continue to use standard license types: Traditional, Concurrent Use, and Personal Use.

• One Traditional capacity License will continue to license the system, regardless of the number of instances. The license is based on the system class of the hardware system.
• Concurrent Use Licenses will continue to license one concurrent use of the product.
• Personal Use Licenses will continue to license one named user on the system.

Instances in an OpenVMS Galaxy computing environment can be clustered with other instances in a single system, with instances in other Galaxy systems, or with non-Galaxy systems. Each type of clustering has different licensing requirements, as described in the following sections.

4.2.1 Clustering in a Galaxy System

In an OpenVMS Galaxy computing environment, instances can be clustered with other instances within a Galaxy system. Clustered instances use the shared-memory cluster interconnect to communicate with each other.

The licensing and functionality for clustering within a Galaxy system is provided under the OpenVMS Galaxy License.

4.2.2 Clustering Outside a Galaxy System

Instances in an OpenVMS Galaxy computing environment can be clustered with instances in another OpenVMS Galaxy system or with cluster nodes in non-Galaxy systems. Instances clustered outside of a Galaxy system use traditional cluster interconnects.

Each system that is clustered with another system must be licensed for OpenVMS Cluster Software. Clustering outside the OpenVMS Galaxy system is not covered by the OpenVMS Galaxy License.

4.3 License Databases

When an OpenVMS Galaxy system is configured with more than one instance, a license database must be set up for each independent instance or cluster of instances. The PAKs representing the licenses on the OpenVMS Galaxy configuration may be loaded on multiple license databases, as follows:

• OpenVMS Base, SMP Extensions, and OpenVMS Galaxy Licenses
  For full use of the OpenVMS Galaxy functionality, the PAKs representing your OpenVMS Base, SMP Extensions, and OpenVMS Galaxy Licenses must be loaded on each license database within the OpenVMS Galaxy on a single system.
• Compaq Layered Product Traditional Capacity Licenses
  The PAKs representing these licenses can be loaded on each license database within the OpenVMS Galaxy on a single system.
• Compaq Concurrent Use Licenses
  The PAKs representing these licenses can be loaded on the license database where the license will be used.
  For PAKs representing multiple concurrent uses (for example, a 50_use license) the PAK can be loaded on multiple license databases within the OpenVMS Galaxy on a single system. However, the PAK must be modified down on each license database so that the total number of license units does not exceed the total license units on the License PAK.
• Compaq Personal Use Licenses
  The PAKs representing these licenses can be loaded on each license database within the OpenVMS Galaxy on a single system; however, the number of actual uses must not exceed the licensed number of personal uses.

OpenVMS Galaxy PAK names are as follows:

• OpenVMS Operating System Base PAK: OPENVMS-ALPHA (base license)
• OpenVMS Operating System User PAK: OPENVMS-ALPHA-USER
• OpenVMS Galaxy PAK: OPENVMS-GALAXY

OpenVMS Galaxy customers must have at least one OPENVMS-ALPHA PAK, plus one additional OPENVMS-ALPHA PAK for each additional processor (CPU) after the first CPU (which is included in the Base Operating System License).

The OPENVMS-ALPHA and OPENVMS-ALPHA-USER PAKs can now be shared by multiple Galaxy instances. To implement this in the License Management Facility (LMF), include all OpenVMS Galaxy instance names in the PAK INCLUDE list.

For example, suppose that a customer has a system named ANDA1A in an OpenVMS Cluster. The OPENVMS-ALPHA license PAK currently has an INCLUDE list on it that has SCS node name ANDA1A in it. If that system is changed to an OpenVMS Galaxy running three instances named ANDA1A, ANDA2A, and ANDA3A, the OPENVMS-ALPHA license PAK must be modified so that all instances can share the NO_SHARE OPENVMS-ALPHA license.

The command to modify the OPENVMS-ALPHA license PAK is:

$ LICENSE MODIFY OPENVMS-ALPHA/AUTHORIZATION=xxxxx- _$ /INCLUDE=3D(ANDA1A,ANDA2A,ANDA3A)

Since this example assumes that ANDA1A was already in a cluster, the authorization number is required to identify the one PAK of many OPENVMS-ALPHA license PAKs in the license database file (LDB).

4.5 For More Information About OpenVMS Licensing

For information about using the OpenVMS Licensing Management Facility, refer to the following books:

• OpenVMS Alpha Upgrade and Installation Manual contains notes and supplemental information about licenses and licensing procedures.
• OpenVMS License Management Utility Manual contains complete, detailed information about OpenVMS licensing procedures.

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
• Memory modules
• Processor modules (2 CPUs per module)

Console line for each partition:

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

Rules:

• 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 (4GB each)

Example Configuration 2

3 partitions, 8 CPUs, 8GB memory

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

5.2 Step 2: Set Up Hardware

The KFE72-DA is the set of EISA-bus modules that establishes an additional console port. One KFE72-DA module set is required per secondary partition.

The KFE72-DA contains three EISA modules that provide:

• Two COM ports
• A keyboard interface
• A mouse interface
• A small speaker
• An Ethernet port.

The COM-1 port is used for the console serial line. The Ethernet port can be used as a network connection or it can be terminated. The mouse and keyboard ports are not used.

The KFE72-DA must be plugged into the bottom three EISA slots. For the AlphaServer 8400 this requires that you attach a hose from your I/O port to a DWLPB PCI card cage. The KFE72-DA module set must be installed in slots 0, 1, and 2 of the card cage. The KFE72's SIO (a.k.a. Bridge) module enables the EISA slots which are part of the combination PCI/EISA backplane. The other two modules known as the "Data Port Module" and "Beeper97" go in slots 1 and 2 respectively.

5.2.2 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.3 Recommendations for Configuring Console Subsystems

Each additional console requires a separate KFE72-DA subsystem installed in a separate DWLPB card cage with a hose connecting it to a separate I/O module of type KFTIA or KFTHA. If you are using a KFTIA, it must be in slot 8.

Additional KFTIA I/O modules must be in the next lower slot or slots, with KFTHA I/O modules in the next lower slot or slots after that.

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

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

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.

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

The console serial line is connected with an H8571-J connector adapter that plugs into the right hand serial line port when viewed from the rear of the machine. This is COM-1.

5.2.4 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>>> SET ARC_ENABLE ON P00>>> INITIALIZE P00>>> RUN ECU

5. Follow the procedures outlined by the ECU and exit when done.
6. P00>>> boot
7. $ @SYS$SYSTEM:SHUTDOWN
8. P00>>> SET ARC_ENABLE OFF
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 in the previous sections, perform the following steps to install and boot OpenVMS Galaxy instances.

5.3 Step 3: Create A System Disk

Decide whether to use a system disk per instance or 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 with Galaxy instances. (For more information, see Section 1.4.)

5.4 Step 4: 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.

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

5.4.1 OpenVMS Galaxy Licensing Information

See Section 4.1.

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 the standard console (that is, the lp_count environment variable---if you have established one---must be set to zero).

Note that the OpenVMS Galaxy firmware (GALAXY_FIRM_072.KIT) is located on the Alpha CD1 for OpenVMS Version 7.2.

Use the following commands:

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

When the firmware update has completed, you must rebuild the EEPROM format on each even-numbered processor module as follows:

P00>>> SET CPU 0 P00>>> BUILD -E P00>>> SET CPU 2 P00>>> BUILD -E . . . P00>>>INIT

Note that a MOP bootable version of the firmware update,
[GALAXY_FIRM_072.KIT]AS8_G53_27.SYS, is also on the CD.

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

LP_COUNT

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

If set to a non-zero 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 non-zero 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. 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 5-1 for common values.

See also the shared memory variable on the following line.

LP_SHARED_MEM_SIZE

This variable allocates memory for use as shared memory. Refer to Table 5-1 for common values.

BOOTDEF_DEV and BOOT_OSFLAGS variables

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 crash or operator requested reboot.

5.6.1 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) P00>>

5.6.2 Table of Useful Integers

Table 5-1 lists common values for Galaxy environment variables. All values are expressed in hexadecimal bytes.

Table 5-1 Useful Integers

1 Megabytes	0x 10 0000
2 Megabytes	0x 20 0000
4 Megabytes	0x 40 0000
8 Megabytes	0x 80 0000
16 Megabytes	0x 100 0000
32 Megabytes	0x 200 0000
64 Megabytes	0x 400 0000
128 Megabytes	0x 800 0000
256 Megabytes	0x 1000 0000
448 Megabytes	0x1C00 0000
512 Megabytes	0x 2000 0000
1 Gigabyte	0x 4000 0000
2 Gigabytes	0x 8000 0000
4 Gigabytes	0x 1 0000 0000
8 Gigabytes	0x 2 0000 0000
16 Gigabytes	0x 4 0000 0000
32 Gigabytes	0x 8 0000 0000
64 Gigabytes	0x 10 0000 0000
128 Gigabytes	0x 20 0000 0000
256 Gigabytes	0x 40 0000 0000
512 Gigabytes	0x 80 0000 0000
1 Terabyte	0x 100 0000 0000

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

6512PRO_002.HTML