7.2 Procedures
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 G52-59 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 en-
abled 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, copy the firmware file AS4_
G52-59.SYS to MOM$SYSTEM on a MOP-enabled
server that is accessible to the AlphaServer 4100. Enter
the following commands on the console:
NEED TO ADD THE CD PROCEDURE.
P00>>> boot -fl 0,0 ewa0 -fi as4_g52-59
UPD> update srm*
<power-cycle system>
4. Configure the primary console for instance 0.
CPU0 is the primary for instance 0.
Create the Galaxy environment variables. For descrip-
tions 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 sec-
ondary CPUs to instance 1, the lp_cpu_mask1 variable
will beE . 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 environ-
ment 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 be-
come DKA300 when it is configured as partition 0 of the
OpenVMS Galaxy.
It is best to wait for the P01>>> prompt on the secondary
console before attempting to boot the primary console.
6. Configure the console for instance 1.
Use the same commands from step 2 to create the same
Galaxy environment variables.
P01>>> create -nv galaxy_cpu_mask0 1
P01>>> create -nv galaxy_cpu_mask1 6
P01>>> create -nv galaxy_io_mask0 10
P01>>> create -nv galaxy_io_mask1 20
P01>>> create -nv galaxy_mem_size0 10000000
P01>>> create -nv galaxy_mem_size1 c000000
P01>>> create -nv galaxy_partitions 2
P01>>> create -nv galaxy_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
If you build a SCSI cluster, make sure to set up your SCSI
adapter host IDs correctly. For example:
P00>>> set pka0_host_id 6
P00>>> set pkb0_host_id 6
P00>>> set kzpsa_host_id 6
P01>>> set pka0_host_id 7
P01>>> set kzpsa_host_id 7
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 ini-
tialization 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 automat-
ically.
Congratulations! You have created an OpenVMS Galaxy.