- 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 starts 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.
- Configure the console for instance 1:
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
- 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)
- 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
- 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 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
- 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
- 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
- Initialize the Galaxy again by entering the following
command 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.