Document revision date: 30 March 2001 | |
Previous | Contents | Index |
If you decide to use the Ethernet port, you may need to inform the console 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:
P00>>> SHOW NETWORK P00>>> SET EWA0_MODE TWISTED |
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.
9.7 Step 7: Initialize the Secondary Consoles
Once you have established the Galaxy variables, to initialize the
secondary consoles, enter:
P00>>> LPINIT |
The console displays the following:
P00>>>lpinit lp_count = 2 lp_mem_size0 = 1800 (6 GB) CPU 0 chosen as primary CPU for partition 0 lp_mem_size1 = 1800 (6 GB) CPU 4 chosen as primary CPU for partition 1 lp_shared_mem_size = 1000 (4 GB) initializing shared memory partitioning system QBB 0 PCA 0 Target 0 Interrupt Count = 2 QBB 0 PCA 0 Target 0 Interrupt CPU = 0 Interrupt Enable = 000011110000d05a Sent Interrupts = 0000100000000010 Enabled Sent Interrupts = 0000100000000010 Acknowledging Sent Interrupt 0000000000000010 for CPU 0 QBB 0 PCA 0 Target 0 Interrupt Count = 1 QBB 0 PCA 0 Target 0 Interrupt CPU = 0 Interrupt Enable = 000011110000d05a Sent Interrupts = 0000100000000000 Enabled Sent Interrupts = 0000100000000000 Acknowledging Sent Interrupt 0000100000000000 for CPU 0 OpenVMS PALcode V1.80-1, Tru64 UNIX PALcode V1.74-1 system = QBB 0 1 2 3 + HS (Hard Partition 0) QBB 0 = CPU 0 1 2 3 + Mem 0 + Dir + IOP + PCA 0 1 + GP (Hard QBB 0) QBB 1 = CPU 0 1 2 3 + Mem 0 + Dir + IOP + PCA 0 1 + GP (Hard QBB 1) QBB 2 = CPU 0 1 2 3 + Mem 0 + Dir + IOP + PCA + GP (Hard QBB 4) QBB 3 = CPU 0 1 2 3 + Mem 0 + Dir + IOP + PCA + GP (Hard QBB 5) partition 0 CPU 0 1 2 3 8 9 10 11 IOP 0 2 private memory size is 6 GB shared memory size is 4 GB micro firmware version is T5.4 shared RAM version is 1.4 hose 0 has a standard I/O module starting console on CPU 0 QBB 0 memory, 4 GB QBB 1 memory, 4 GB QBB 2 memory, 4 GB QBB 3 memory, 4 GB total memory, 16 GB probing hose 0, PCI probing PCI-to-ISA bridge, bus 1 bus 1, slot 0 -- dva -- Floppy bus 0, slot 1 -- pka -- QLogic ISP10x0 bus 0, slot 2 -- pkb -- QLogic ISP10x0 bus 0, slot 3 -- ewa -- DE500-BA Network Controller bus 0, slot 15 -- dqa -- Acer Labs M1543C IDE probing hose 1, PCI probing hose 2, PCI bus 0, slot 1 -- fwa -- DEC PCI FDDI probing hose 3, PCI starting console on CPU 1 starting console on CPU 2 starting console on CPU 3 starting console on CPU 8 starting console on CPU 9 starting console on CPU 10 starting console on CPU 11 initializing GCT/FRU at 1fa000 initializing pka pkb ewa fwa dqa Testing the System Testing the Disks (read only) Testing the Network AlphaServer Console X5.8-2842, built on Apr 6 2000 at 01:43:42 P00>>> |
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 that the primary CPU in each instance has started.
If one or more consoles fails to initialize, you should double-check
your hardware installation, Galaxy partition definitions, and hardware
assignments.
9.8 Step 8: Boot the OpenVMS Galaxy
When you have correctly installed the Galaxy firmware and configured the consoles, you can boot the initial Galaxy environment as follows:
For each Galaxy instance:
P00>>> B -FL 0,1 DKA100 // or whatever your boot device is. SYSBOOT> SET GALAXY 1 SYSBOOT> CONTINUE |
Congratulations! You have created an OpenVMS Galaxy.
With OpenVMS Alpha Version 7.3, you can run a single-instance Galaxy on any Alpha platform. This capability allows early adopters to evaluate OpenVMS Galaxy features and, most important, to develop and test Galaxy-aware applications without incurring the expense of setting up a full-scale Galaxy computing environment on a system capable of running multiple instances of OpenVMS (for example, an AlphaServer 8400).
A single-instance Galaxy running on any Alpha system is not an emulator. It is OpenVMS Galaxy code with Galaxy interfaces and underlying operating system functions. All Galaxy APIs are present in a single-instance Galaxy (for example, resource management, shared memory access, event notification, locking for synchronization, and shared memory for global sections).
Any application that is run on a single-instance Galaxy will exercise the identical operating system code on a multiple-instance Galaxy system. This is accomplished by creating the configuration file SYS$SYSTEM:GLX$GCT.BIN, which OpenVMS reads into memory. On a Galaxy platform (for example, an AlphaServer 8400), the console places configuration data in memory for OpenVMS to use. Once the configuration data is in memory, regardless of its origin, OpenVMS boots as a Galaxy instance.
To use the Galaxy Configuration Utility (GCU) to create a single-instance Galaxy on any Alpha system, use the following procedure:
Run the GCU on the OpenVMS Alpha system on which you want to use the single-instance Galaxy.
If the GCU is run on a non-Galaxy system, it will prompt as to whether you want to create a single-instance Galaxy. Click on OK.
The GCU next prompts for the amount of memory to designate as shared memory. Enter any value that is a multiple of 8 MB. Note that you must specify at least 8 MB of shared memory if you want to boot as a Galaxy instance.
When the GCU has displayed the configuration, it will already have written the file GLX$GCT.BIN to the current directory. You can exit the GCU at this point. If you made a mistake or want to alter the configuration, you can close the current model and repeat the process.
To reboot the system as a Galaxy instance:
This chapter contains information that OpenVMS Engineering has found
useful in creating and running OpenVMS Galaxy environments.
11.1 System Auto-Action
Upon system power-up, if the AUTO_ACTION console environment variable is set to BOOT or RESTART for instance 0, then the GALAXY command will automatically be issued and instance 0 will attempt to boot.
The setting of AUTO_ACTION in the console environment variables for the other instances will dictate their behavior upon the issuing of the GALAXY comamnd (whether it is issued automatically or by the user from the console).
To setup your system for this feature, you must set the console
environment variable AUTO_ACTION to RESTART or BOOT on each instance,
and be sure to specify appropriate values for the BOOT_OSFLAGS and
BOOTDEF_DEV environment variables for each instance.
11.2 Changing Console Environment variables
Once you have established the initial set of LP_* environment variables for OpenVMS Galaxy operation and booted your system, changing environment variable values requires that you first reinitialize the system, change the values, and reinitialize again. Wrapping the changes between INIT commands is required to properly propagate the new values to all partitions.
For AlphaServer 4100 systems no INIT command is needed to start, but you must change these variables on both instances. |
Because AlphaServer 8400 and 8200 systems were designed prior to the Galaxy Software Architecture, OpenVMS Galaxy console firmware and system operations must handle a few restrictions.
The following list briefly describes some things you should be aware of and some things you should avoid doing:
If you want to turn off OpenVMS Galaxy software, change the lp_count environment variable as follows and enter the following commands:
>>> SET LP_COUNT 0 ! Return to monolithic SMP config >>> INIT ! Return to single SMP console >>> B -fl 0,1 device ! Stop at SYSBOOT SYSBOOT> SET GALAXY 0 SYSBOOT> CONTINUE |
The Galaxy Configuration Utility (GCU) is a DECwindows Motif application that allows system managers to configure and manage an OpenVMS Galaxy system from a single workstation window.
Using the GCU, system managers can:
The GCU resides in the SYS$SYSTEM directory along with a small number of files containing configuration knowledge.
The GCU consists of the following files:
SYS$SYSTEM:GCU.EXE | GCU executable image |
SYS$MANAGER:GCU.DAT | Optional DECwindows resource file |
SYS$MANAGER:GALAXY.GCR | Galaxy Configuration Ruleset |
SYS$MANAGER:GCU$ACTIONS.COM | System management procedures |
SYS$MANAGER: xxx.GCM | User-defined configuration models |
SYS$HELP:GALAXY_GUIDE.DECW$BOOK | Online help in Bookreader form |
The GCU can be run from any Galaxy instance. If the system does not directly support graphics output, then the DECwindows display can be set to an external workstation or suitably configured PC. However, the GCU application itself must always run on the Galaxy system.
When the GCU is started, it loads any customizations found in its resource file (GCU.DAT); then it loads the Galaxy Configuration Ruleset (GALAXY.GCR). The ruleset file contains statements that determine the way the GCU displays the various system components, and includes rules that govern the ways in which users can interact with the configuration display. Users do not typically alter the ruleset file unless they are well versed in its structure or are directed to do so by a Compaq Services Engineer. After the GCU display becomes visible, the GCU determines whether the system is currently configured as an OpenVMS Galaxy or as a single-instance Galaxy on a non-Galaxy platform. If the system is configured as a Galaxy, the GCU displays the active Galaxy configuration model. The main observation window displays a hierarchical view of the Galaxy. If the system has not yet been configured as a Galaxy, the GCU prompts you as to whether or not to create a single-instance Galaxy. Note that the GCU can create a single-instance Galaxy on any Alpha system, but multiple-instance OpenVMS Galaxy environments are created by using console commands and console environment variables.
Once the Galaxy configuration model is displayed, users can either
interact with the active model or take the model off line and define
specific configurations for later use. The following sections discuss
these functions in greater detail.
12.1 GCU Tour
The GCU can perform three types of operations:
Most GCU operations are organized around the main observation window and its hierarchical display of Galaxy components. The observation window provides a porthole into a very large space. The observation window can be panned and zoomed as needed to observe part of or all of the entire Galaxy configuration. The main toolbar contains a set of buttons that control workspace zoom operations. Workspace panning is controlled by the horizontal and vertical scrollbars; workspace sliding is achieved by holding down the middle mouse button as you drag the workspace around. This obviously assumes you have a three-button mouse.
The various GCU operations are invoked from pull-down or pop-up menu functions. General operations such as opening and closing files, and invoking external tools, are accomplished using the main menu bar entries. Operations specific to individual Galaxy components are accomplished using pop-up menus that appear whenever you click the right mouse button on a component displayed in the observation window.
In response to many operations, the GCU displays additional dialog
boxes containing information, forms, editors, or prompts. Error and
information responses are displayed in pop-up dialog boxes or inside
the status bar along the bottom of the window, depending on the
severity of the error and importance of the message.
12.1.1 Creating Galaxy Configuration Models
You can use the GCU to create Galaxy configuration models and a single-instance Galaxy on any Alpha system.
When viewing the active Galaxy configuration model, direct manipulation of display objects (components) may alter the running configuration. For example, dragging a CPU from its current location and dropping it on top of a different instance component will invoke a management action procedure that reassigns the selected CPU to the new instance. At certain times this may be a desirable operation; however, in other situations you might want to reconfigure your Galaxy all at once rather than component by component. To accomplish this, you must create an offline Galaxy configuration model.
To create a Galaxy configuration model, we must start with an existing model, typically the active one, alter it in some manner, and save it in a file.
Starting from the active Galaxy Configuration Model:
The reason for creating offline models is to allow significant
configuration changes to be automated. For example, you can create
models representing the desired Galaxy configuration at different times
and then engage the models interactively by following this procedure.
12.1.2 Observation
The GCU can display the single active Galaxy configuration model, or any number of offline Galaxy configuration models. Each loaded model appears as an item in the Model menu on the toolbar. You can switch between models by clicking the desired menu item.
The active model is always named GLX$ACTIVE.GCM. When the active model is first loaded, a file by this name will exist briefly as the system verifies the model with the system hardware.
When a model is visible, you can zoom, pan, or slide the display as needed to view Galaxy components. Use the buttons on the left side of the toolbar to control the zoom functions.
The zoom functions include:
Galactic zoom | Zoom to fit the entire component hierarchy into observation window. |
Zoom 1:1 | Zoom to the component normal scale. |
Zoom to region | Zoom to a selected region of the display. |
Zoom in | Zoom in by 10 percent. |
Zoom out | Zoom out by 10 percent. |
Panning is accomplished by using the vertical and horizontal
scrollbars. Sliding is done by pressing and holding the middle mouse
button and dragging (sliding) the cursor and the image.
12.1.2.1 Layout Management
The Automatic Layout feature manages the component layout. If you ever need to refresh the layout while in Automatic Layout mode, simply select the root (topmost) component.
To alter the current layout, select Manual Layout from the Windows menu. In Manual Layout Mode, you can freely drag and drop components however you like to generate a pleasing structure. Because each component is free from automatic layout constraints, you may need to invest some time in positioning each component, possibly on each of the charts. To make things simpler, you can click the right mouse button on any component and select Layout Subtree to provide automatic layout assistance below that point in the hierarchy.
When you are satisfied with the layout, you must save the current model
in a file to retain the manual layout information. The custom layout is
used when the model is open. Note that if you select Auto Layout mode,
your manual layout will be lost for the in-memory model. Also, in order
for CPU components to reassign in a visually effective manner, they
must perform subtree layout operations below the instance level. For
this reason, it is best to limit any manual layout operations to the
instance and community levels of the component hierarchy.
12.1.2.2 OpenVMS Galaxy Charts
The GCU provides six distinct subsets of the model, known as charts.
The six charts include:
Chart Name | Shows |
---|---|
Logical Structure | Dynamic resource assignments |
Physical Structure | Nonvolatile hardware relationships |
CPU Assignment | Simplified view of CPU assignments |
Memory Assignment | Memory subsystem components |
IOP Assignment | I/O module relationships |
Failover Targets | Processor failover assignments |
These charts result from enabling or disabling the display of various component types to provide views of sensible subsets of components.
Specific charts may offer functionality that can be provided only for that chart type. For example, reassignment of CPUs requires that the instance components be visible. Because instances are not visible in the Physical Structure or Memory Assignment charts, you can reassign CPUs only in the Logical Structure and CPU Assignment charts.
For more information about charts, refer to Section 12.4.
12.1.3 Interaction
When viewing the active Galaxy configuration model, you can interact directly with the system components. For example, to reassign a CPU from one instance to another, you can drag and drop a CPU onto the desired instance. The GCU will validate the operation and execute an external command action to make the configuration change. Interacting with a model that is not engaged, is simply a drawing operation on the offline model, and has no impact to the running system.
While interacting with Galaxy components, the GCU applies built-in and user-defined rules that prevent misconfiguration and improper management actions. For example, you cannot reassign primary CPUs, and you cannot reassign a CPU to any component other than a Galaxy instance. Either operation would result in an error message on the status bar, and the model would return to its proper configuration. If the attempted operation violates one of the configuration rules, the error message, displayed in red on the status bar, will describe the rule that fired.
You can view details for any selected component by clicking the right mouse button and either selecting the Parameters item from the pop-up menu or by selecting Parameters from the Components menu on the main toolbar.
The GCU can shut down or reboot one or more Galaxy instances using the Shutdown or Reboot items on the Galaxy menu. The various shutdown or reboot parameters can be entered in the Shutdown dialog box. Be sure to specify the CLUSTER_SHUTDOWN option to fully shut down clustered Galaxy instances. The Shutdown dialog box allows you to select any combination of instances, or all instances. The GCU is "smart" enough to shut down its owner instance last.
Previous | Next | Contents | Index |
privacy and legal statement | ||
6512PRO_006.HTML |