Document revision date: 30 March 2001

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

Note that this chapter contains revised procedures that were originally published in the OpenVMS Alpha VMS721_DS20E_ES40 remedial kit.

To create an OpenVMS Galaxy on an AlphaServer ES40 system:

1. Read the configuration and hardware requirements in Section 8.1.
2. Perform the steps in Section 8.2 through Section 8.6.

You must be familiar with the following AlphaServer ES40 configuration and hardware requirements:

Two-instance maximum

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

Console firmware

To create an OpenVMS Galaxy environment on AlphaServer ES40 systems, you must download the latest version of the V5.6-xx console firmware from the following location:

http://ftp.digital.com/pub/DEC/Alpha/firmware/

AlphaServer ES40 clock

An AlphaServer ES40 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

On a rack-mounted system:
COM1 (lower) is the console port for instance 0.
COM2 (upper) is the console port for instance 1.

On a pedestal system:
COM1 (left) is the console port for instance 0.
COM2 (right) 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. COM2 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.

For an example of the CPU environment variable settings on an AlphaServer ES40, see Section 8.5.

I/O adapters

On a rack-mounted system:
PCI Hose 0 (PCI0) belongs to instance 0 (upper 4 PCI slots)
PCI Hose 1 (PCI1) belongs to instance 1 (lower 6 PCI slots)

On a pedestal system:
PCI Hose 0 (PCI0) belongs to instance 0 (right-hand slots)
PCI Hose 1 (PCI1) belongs to instance 1 (left-hand slots)

Note that PCI0 contains an embedded ISA controller.

To see an I/O adapter configuration example, refer to Section 8.2.

Storage controllers

You will need one storage controller (such as a KZPSA) per instance. For each instance, this can go to a separate StorageWorks box or to the same box for running as a SCSI cluster.

Network cards

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

One card each goes in PCI0 and PCI1.

Memory Granularity Restrictions

Private memory must start on a 64 MB boundary.

Shared memory must start on an 8 MB boundary.

Instance 0 must have a multiple of 64 MB.

8.2 Step 1: Confirm the AlphaServer ES40 Configuration

Use the SHOW CONFIG command to make sure that the AlphaServer ES40 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 information similar to the following example:

Firmware SRM Console: X5.6-2323 ARC Console: v5.70 PALcode: OpenVMS PALcode V1.61-2, Tru64 UNIX PALcode V1.54-2 Serial Rom: V2.2-F RMC Rom: V1.0 RMC Flash Rom: T2.0 Processors CPU 0 Alpha 21264-4 500 MHz 4MB Bcache CPU 1 Alpha 21264-4 500 MHz 4MB Bcache CPU 2 Alpha 21264-4 500 MHz 4MB Bcache CPU 3 Alpha 21264-4 500 MHz 4MB Bcache Core Logic Cchip DECchip 21272-CA Rev 9(C4) Dchip DECchip 21272-DA Rev 2 Pchip 0 DECchip 21272-EA Rev 2 Pchip 1 DECchip 21272-EA Rev 2 TIG Rev 10 Memory Array Size Base Address Intlv Mode --------- ---------- ---------------- ---------- 0 4096Mb 0000000000000000 2-Way 1 4096Mb 0000000100000000 2-Way 2 1024Mb 0000000200000000 2-Way 3 1024Mb 0000000240000000 2-Way 10240 MB of System Memory Slot Option Hose 0, Bus 0, PCI 1 DAPCA-FA ATM622 MMF 2 DECchip 21152-AA Bridge to Bus 2, PCI 3 DEC PCI FDDI fwb0.0.0.3.0 00-00-F8-BD-C6-5C 4 DEC PowerStorm 7 Acer Labs M1543C Bridge to Bus 1, ISA 15 Acer Labs M1543C IDE dqa.0.0.15.0 dqb.0.1.15.0 dqa0.0.0.15.0 TOSHIBA CD-ROM XM-6302B 19 Acer Labs M1543C USB Option Hose 0, Bus 1, ISA Floppy dva0.0.0.1000.0 Slot Option Hose 0, Bus 2, PCI 0 NCR 53C875 pkd0.7.0.2000.0 SCSI Bus ID 7 1 NCR 53C875 pke0.7.0.2001.0 SCSI Bus ID 7 dke100.1.0.2001.0 RZ1BB-CS dke200.2.0.2001.0 RZ1BB-CS dke300.3.0.2001.0 RZ1CB-CS dke400.4.0.2001.0 RZ1CB-CS 2 DE500-AA Network Con ewa0.0.0.2002.0 00-06-2B-00-0A-58 Slot Option Hose 1, Bus 0, PCI 1 NCR 53C895 pka0.7.0.1.1 SCSI Bus ID 7 dka100.1.0.1.1 RZ2CA-LA dka300.3.0.1.1 RZ2CA-LA 2 Fore ATM 155/622 Ada 3 DEC PCI FDDI fwa0.0.0.3.1 00-00-F8-45-B2-CE 4 QLogic ISP10x0 pkb0.7.0.4.1 SCSI Bus ID 7 dkb100.1.0.4.1 HSZ50-AX dkb101.1.0.4.1 HSZ50-AX dkb200.2.0.4.1 HSZ50-AX dkb201.2.0.4.1 HSZ50-AX dkb202.2.0.4.1 HSZ50-AX 5 QLogic ISP10x0 pkc0.7.0.5.1 SCSI Bus ID 7 dkc100.1.0.5.1 RZ1CB-CS dkc200.2.0.5.1 RZ1CB-CS dkc300.3.0.5.1 RZ1CB-CS dkc400.4.0.5.1 RZ1CB-CS 6 DECchip 21154-AA Bridge to Bus 2, PCI Slot Option Hose 1, Bus 2, PCI 4 DE602-AA eia0.0.0.2004.1 00-08-C7-91-0A-AA 5 DE602-AA eib0.0.0.2005.1 00-08-C7-91-0A-AB 6 DE602-TA eic0.0.0.2006.1 00-08-C7-66-80-9E 7 DE602-TA eid0.0.0.2007.1 00-08-C7-66-80-5E

8.3 Step 2: 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.

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

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

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

8.4 Step 3: Upgrade the Firmware

To upgrade the firmware, use one of the following procedures:

Copy the firmware file to MOM$SYSTEM on a MOP-enabled server that is accessible to the AlphaServer ES40. Enter the following commands on the console:

P00>>> boot -fl 0,0 ewa0 -fi {firmware filename} UPD> update srm* <power-cycle system>

Or, use the following commands:

P00>>> BOOT -FLAGS 0,A0 cd_device_name . . . Bootfile: {firmware filename} . . .

8.5 Step 4: Set Environment Variables

Configure the primary console for instance 0.

CPU0 is the primary for instance 0. CPU1 is the primary for instance 1.

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

P00>>> set lp_count 2 P00>>> set lp_cpu_mask0 1 P00>>> set lp_cpu_mask1 6 P00>>> set lp_io_mask0 1 P00>>> set lp_io_mask1 2 P00>>> set lp_mem_size0 10000000 P00>>> set lp_mem_size1 c000000 P00>>> set lp_shared_mem_size 4000000 P00>>> set console_memory_allocation new 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 following example shows LP_CPU_MASK values for secondary CPU assignments with primary CPUs.

Assign secondary CPU 2 with primary CPU 0 and secondary CPU 3 with primary CPU 1. >>>set lp_cpu_mask0 5 >>>set lp_cpu_mask1 A CPU Selection LP_CPU_MASK 0(primary partition 0) 2^0 = 1 1(primary partition 1) 2^1 = 2 2(secondary) 2^2 = 4 3(secondary) 2^3 = 8

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

lp_io_mask0 must be set to 1.
lp_io_mask1 must be set to 2.

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 LPINIT 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 ! initialize the system P00>>> lpinit ! start firmware

   
   After the self-test completes, the Galaxy command will start the console 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 ES40 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.
3. 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.

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

4. 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 SCSNODE and SCSSYSTEMID SYSGEN parameters 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

5. 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:

   GALAXY=1

   
   Confirm that the SCSNODE and SCSSYSTEMID SYSGEN parameters 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

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

7. 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 all partitions? (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 on an AlphaServer ES40 system.

This chapter describes how to create an OpenVMS Galaxy computing environment on AlphaServer GS80/160/320 systems.

9.1 Step 1: Choose a Configuration and Determine Hardware Requirements

OpenVMS Alpha Version 7.3 supports the following maximum configuration on AlphaServer GS160 systems:

4 instances
4 QBBs
16 CPUs
64 GB memory

Rules:

Must have standard COM1 UART console line for each partition
Must have PCI drawer for each partition
Must have an I/O module per partition
Must have at least one CPU module per partition
Must have at least one memory module per partition.

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

9.3 Step 3: Create a System Disk

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

A new SECURITY.EXE file 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.

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

9.4.1 OpenVMS Galaxy Licensing Information

In a Galaxy environment, the OPENVMS-GALAXY license units are checked during system startup and whenever a CPU reassignment between instances occurs.

If you attempt to start a CPU and there are insufficient OPENVMS-GALAXY license units to support it, the CPU will remain in the instance's configured set but it will be stopped. You can subsequently load the appropriate license units and start the stopped CPU while the system is running. This is true of one or more CPUs.

9.5 Step 5: Set Environment Variables

When you have installed the operating system, you can set the Galaxy-specific environment variables as shown in the examples in this section.

9.5.1 AlphaServer GS160 Example

4 instances
4 QBBs
16 CPUs
32 GB of memory

P00>>>show lp* lp_count 4 lp_cpu_mask0 000F lp_cpu_mask1 00F0 lp_cpu_mask2 0F00 lp_cpu_mask3 F000 lp_cpu_mask4 0 lp_cpu_mask5 0 lp_cpu_mask6 0 lp_cpu_mask7 0 lp_error_target 0 lp_io_mask0 1 lp_io_mask1 2 lp_io_mask2 4 lp_io_mask3 8 lp_io_mask4 0 lp_io_mask5 0 lp_io_mask6 0 lp_io_mask7 0 lp_mem_size0 0=4gb lp_mem_size1 1=4gb lp_mem_size2 2=4gb lp_mem_size3 3=4gb lp_mem_size4 0 lp_mem_size5 0 lp_mem_size6 0 lp_mem_size7 0 lp_shared_mem_size 16gb P00>>>lpinit

9.5.2 AlphaServer GS320 Example

This example for an AlphaServer GS320 system assumes you are configuring an OpenVMS Galaxy computing environment with:

4 instances
8 QBBs
32 CPUs
32 GB memory

P00>>>show lp* lp_count 4 lp_cpu_mask0 000F000F lp_cpu_mask1 00F000F0 lp_cpu_mask2 0F000F00 lp_cpu_mask3 F000F000 lp_cpu_mask4 0 lp_cpu_mask5 0 lp_cpu_mask6 0 lp_cpu_mask7 0 lp_error_target 0 lp_io_mask0 11 lp_io_mask1 22 lp_io_mask2 44 lp_io_mask3 88 lp_io_mask4 0 lp_io_mask5 0 lp_io_mask6 0 lp_io_mask7 0 lp_mem_size0 0=2gb, 4=2gb lp_mem_size1 1=2gb, 5=2gb lp_mem_size2 2=2gb, 6=2gb lp_mem_size3 3=2gb, 7=2gb lp_mem_size4 0 lp_mem_size5 0 lp_mem_size6 0 lp_mem_size7 0 lp_shared_mem_size 16gb P00>>>lpinit

9.5.3 Environment Variable Descriptions

This section describes each environment variable. For more details about using these variables, refer to the AlphaServer GS80/160/320 Firmware Reference Manual.

LP_COUNT number

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

Note that if you assign resources for three partitions and set LP_COUNT to two, the remaining resources will be left unassigned.

LP_CPU_MASKn mask

This bitmask determines which CPUs are to be initially assigned to the specified Galaxy partition number. The AlphaServer GS160 console chooses the first CPU that passes the self test in a partition as its primary CPU.

LP_ERROR_TARGET

The new Alphaserver GS series introduces a new Galaxy environment variable called LP_ERROR_TARGET. The value of the variable is the number of the Galaxy instance that system errors will initially be reported to. Unlike other Galaxy platforms, all system correctable, uncorrectable and system event errors will go to a single instance. It is possible for the operating system to change this target, so the value of the variable represents the target when the system is first partitioned.

Every effort is made to isolate system errors to a single instance so that the error does not bring down the entire Galaxy. The error target instance will determine, on receipt of an error, if it is safe to remotely crash the single instance that incurred the error. A bugcheck code of GLXRMTMCHK is used in this case. Note that error log information pertaining to the error will be on the error target instance, not necessarily on the instance that incurred the error.

While every effort is made to keep the error target instance identical to the one the user designated with the environment variable, the software monitors the instances and will change the error target if necessary.

LP_IO_MASKn mask

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

Mask Value	QBB Number
1	QBB 0
2	QBB 1
4	QBB 2
8	QBB 3

For the n, supply the partition number (0 - 7). The value mask gives a binary mask indicating which QBB's (containing I/O risers) are included in the partition.

LP_MEM_SIZEn size

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.

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 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 leave other partition memory assignments undefined, the console will again assign the memory fragments for shared memory and any partitions with explicit assignments, then split and assign the remaining memory to any remaining partitions not having explicit memory assignments.

For example:

lp_mem_size0 0=2gb, 1=2gb

Refer to see AlphaServer GS80/160/320 Firmware Reference Manual for more details about using this variable.

LP_SHARED_MEM_SIZE size

This variable allocates memory for use as shared memory. For example:

lp_shared_mem_size 16gb

Note that shared memory must be assigned in multiples of 8 MB.

Refer to the AlphaServer GS80/160/320 Firmware Reference Manual for more details about using this variable.

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

	privacy and legal statement
6512PRO_005.HTML