Document revision date: 19 July 1999

Each component has a set of parameters that can be displayed and, in some cases, altered. To display a component's parameters, position the cursor on the desired component, click the right mouse button, and select the Parameters item from the pop-up menu entry. Alternately, you can select a component, then select the Parameters item from the Components menu.

Where parameters are subject to unit conversion, changing the display unit will update the display and any currently visible parameter dialog boxes. Other parameters represent a snapshot of the system component and are not dynamically updated. If these parameters change, you must close and then reopen the Parameters dialog box to see the updated values.

11.6 Executing Component Commands

A component's Parameters dialog box can also contain a command page. If so, you can access the commands by clicking on the Commands button at the top of the dialog box. Most of the commands are executed by clicking on their toggle buttons and then clicking the OK or Apply buttons. Other commands may require that you enter information, or select values from a list or option menu. Note that if you select several commands, they will be executed in a top-down order. Be sure to choose command sequences that are logical.

11.7 Customizing GCU Menus

System Managers can extend and customize the GCU menus and menu entries by creating a file named SYS$MANAGER:GCU$CUSTOM.GCR. The file must contain only menu statements formatted as illustrated in the following examples. The GCU$CUSTOM.GCR file is optional. It will be preserved during operating system upgrades.

FORMAT EXAMPLE: MENU "Menu-Name" "Entry-Name" Procedure-type "DCL-command" * Menu-Name - A quoted string representing the name of the pulldown menu to add or extend. * Entry-Name - A quoted string representing the name of the menu entry to add. * Procedure-type - A keyword describing the type of procedure to invoke when the menu entry is selected. Valid Procedure-type keywords include: COMMAND_PROCEDURE - Executes a DCL command or command file. SUBPROC_PROCEDURE - Executes a DCL command in subprocess context. * DCL-command - A quoted string containing a DCL command statement consisting of an individual command or invokation of a command procedure.

To create a procedure to run on other instances, create a command procedure that uses SYSMAN or task-to-task methods similar to what the GCU uses in SYS$MANAGER:GCU$ACTIONS.COM. You can extend GCU$ACTIONS.COM, but this file will be replaced during operating system upgrades and is subject to change.

EXAMPLE MENU STATEMENTS (place in SYS$MANAGER:GCU$CUSTOM.GCR): // GCU$CUSTOM.GCR - GCU menu customizations // Note that the file must end with the END-OF-FILE statement. // MENU "Tools" "Availability Manager" SUBPROC_PROCEDURE "AVAIL/GROUP=DECamds" MENU "Tools" "Create DECterm" COMMAND_PROCEDURE "CREATE/TERM/DETACH" MENU "DCL" "Show CPU" COMMAND_PROCEDURE "SHOW CPU" MENU "DCL" "Show Memory" COMMAND_PROCEDURE "SHOW MEMORY" MENU "DCL" "Show System" COMMAND_PROCEDURE "SHOW SYSTEM" MENU "DCL" "Show Cluster" COMMAND_PROCEDURE "SHOW CLUSTER" END-OF-FILE

11.8 Monitoring an OpenVMS Galaxy with DECamds

The DECamds availability manager software provides a valuable real-time view of the Galaxy system. DECamds can monitor all Galaxy instances from a single workstation or PC anywhere on the local area network. DECamds utilizes a custom OpenVMS driver (RMDRIVER) that periodically gathers availability data from the system. This information is returned to the DECamds client application using a low-level Ethernet protocol. The client application provides numerous views and graphs of the system's availability characteristics. Additionally, when DECamds detects one of numerous known conditions, it notifies the user and offers a set of solutions (called fixes) that can be applied to resolve the condition.

Every OpenVMS system comes with the DECamds Data Collector (RMDRIVER) installed. To enable the collector, you must execute its startup procedure inside SYSTARTUP_VMS.COM or manually on each Galaxy instance you want to monitor. Use the following commands to start the data collector:

$ @SYS$STARTUP:AMDS$STARTUP START or STOP

Prior to starting the collector, you need to specify a group name for your Galaxy. Do so by editing the file SYS$COMMON:[AMDS]AMDS$LOGICALS.COM. This file includes a statement for declaring a group name. Choose any unique name, making sure this file on each Galaxy instance contains the same group name.

When using DECamds, OpenVMS Engineering finds it useful to display the System Overview window, the Event window, and a CPU Summary window for each Galaxy instance. There are a number of additional views you can monitor depending on your specific interests. For more information about DECamds, refer to the DECamds Users Guide.

11.9 Running the CPU Load Balancer Program

The OpenVMS Galaxy CPU Load balancer program is a privileged application that dynamically reassigns CPU resources among instances in an OpenVMS Galaxy.

For information about how to run this program from the GCU, see Appendix A.

11.10 Creating an Instance

The current implementation of the Galaxy Software Architecture for OpenVMS requires that you predefine the Galaxy instances you intend to use. You can do this by using console environment variables. Refer to the appropriate sections of this guide for more details about Galaxy environment variables.

11.11 Dissolving an Instance

The only way to effectively dissolve a Galaxy instance is to shut it down, reassign its resources using console environment variables, and, if necessary, reboot any instances that will acquire new resources.

11.12 Shutdown and Reboot Cycles

Resources such as CPUs can be dynamically reassigned once the involved instances are booted. To reassign statically assigned resources, such as I/O modules, you must shut down and reboot the involved instances after executing the appropriate console commands.

11.13 Online versus Offline Models

The GCU allows you to display and interact with the active (online) or inactive (offline) Galaxy configuration models. When the configuration display represents a model of the active system, the GCU displays the state of the CPUs and instances using color and text. When the configuration model is engaged in this manner, you can interact with the active system using drag-and-drop procedures. The formal description for this mode of operation is interacting with the engaged, online model.

GCU users can also interact with any number of disengaged, or offline, models. Offline models can be saved to or loaded from files. An offline model can also be derived from the active online model by clicking the Engage button to be disengaged when the active online model is displayed. In addition to the visual state of the Engage button, the GCU also indicates the online versus offline characteristic of the CPUs and instances by using color and text. Any drag-and-drop actions directed at an offline model are interpreted as simple editing functions. They change the internal structure of the model but do not affect the active system.

When an offline model is engaged, the GCU compares the structure of the model with that of the active system. If they agree, the offline model is engaged and its new online state is indicated with color and text. If they do not agree, the GCU determines what management actions would be required to alter the active system to match the proposed model. A list of the resulting management actions is presented to the user and the user is asked whether they would like to execute the action list. If the user disapproves, the model remains offline and disengaged. If the user approves, the GCU executes the management actions and the resulting model is displayed as online and engaged.

11.14 GCU System Messages

%GCU-E-SUBPROCHALT, Subprocess halted; See GCU.LOG. The GCU has launched a user-defined subprocess which has terminated with error status. Details may be found in the file GCU.LOG. %GCU-S-SUBPROCTERM, Subprocess terminated The GCU has launched a user-defined subprocess which has terminated. %GCU-I-SYNCMODE, XSynchronize activated The GCU has been invoked with X-windows synchronous mode enabled. This is a development mode which is not generally used. %GCU-W-NOCPU, Unable to locate CPU A migration action was initiated which involved an unknown CPU. This can result from engaging a model which contains invalid CPU identifiers for the current system. %GCU-E-NORULESET, Ruleset not found: The GCU was unable to locate the Galaxy Configuration Ruleset in SYS$MANAGER:GALAXY.GCR. New versions of this file can be downloaded from the OpenVMS Galaxy web page. %GCU-E-NOMODEL, Galaxy configuration model not found: The specified Galaxy Configuration Model was not found. Check your command line model file specification. %GCU-W-XTOOLKIT, X-Toolkit Warning: The GCU has intercepted an X-Toolkit warning. You may or may not be able to continue, depending on the type of warning. %GCU-S-ENGAGED, New Galaxy configuration model engaged The GCU has successfully engaged a new Galaxy Configuration Model. %GCU-E-DISENGAGED, Unable to engage Galaxy configuration model The GCU has failed to engage a new Galaxy Configuration Model. This can happen when a specified model is invalid for the current system, or when other system activities prevent the requested resource assignments. %GCU-E-NODECW, DECwindows is not installed. The current system does not have the required DECwindows support. %GCU-E-HELPERROR Help subsystem error. The DECwindows Help system (Bookreader) encountered an error. %GCU-E-TOPICERROR Help topic not found. The DECwindows Help system could not locate the specified topic. %GCU-E-INDEXERROR Help index not found. The DECwindows Help system could not locate the specified index. %GCU-E-UNKNOWN_COMPONENT: {name} The current model contains reference to an unknown component. This can result from model or ruleset corruption. Search for the named component in the ruleset SYS$MANAGER:GALAXY.GCR. If it is not found, download a new one from the OpenVMS Galaxy web site. If the problem persists, delete and recreate the offending model. %GCU-I-UNASSIGNED_HW: Found unassigned {component}" The GCU has detected a hardware component which is not currently assigned to any Galaxy instance. This may result from intentionally leaving unassigned resources. Note the message and continue or assign the hardware component from the primary Galaxy console and reboot. %GCU-E-UNKNOWN_KEYWORD: {word} The GCU has parsed an unknown keyword in the current model file. This can only result from model file format corruption. Delete and recreate the offending model. %GCU-E-NOPARAM: Display field {field name} The GCU has parsed an incomplete component statement in the current model. This can only result from model file format corruption. Delete and recreate the offending model. %GCU-E-NOEDITFIELD: No editable field in display. The GCU has attempted to edit a component parameter which is undefined. This can only result from model file format corruption. Delete and recreate the offending model. %GCU-E-UNDEFTYPE, Undefined Parameter Data Type: {type} The GCU has parsed an unknown data type in a model component parameter. This can result from model file format corruption or incompatible ruleset for the current model. Search the ruleset SYS$MANAGER:GALAXY.GCR for the offending datatype. If not found, download a more recent ruleset from the OpenVMS Galaxy web site. If found, delete and recreate the offending model. %GCU-E-INVALIDMODEL, Invalid model structure in: {model file} The GCU attempted to load an invalid model file. Delete and recreate the offending model. %GCU-F-TERMINATE Unexpected termination. The GCU encountered a fatal DECwindows event. %GCU-E-GCTLOOP: Configuration Tree Parser Loop The GCU has attempted to parse a corrupt configuration tree. This may be a result of console firmware or operating system fault. %GCU-E-INVALIDNODE: Invalid node in Configuration Tree The GCU has parsed an invalid structure within the configuration tree. This can only result from configuration tree corruption or revision mismatch between the ruleset and console firmware. %GCU-W-UNKNOWNBUS: Unknown BUS subtype: {type} The GCU has parsed an unknown bus type in the current configuration tree. This can only result from revision mismatch between the ruleset and console firmware. %GCU-W-UNKNOWNCTRL, Unknown Controller type: {type} The GCU has parsed an unknown controller type in the current configuration tree. This can only result from revision mismatch between the ruleset and console firmware. %GCU-W-UNKNOWNCOMP, Unknown component type: {type} The GCU has parsed an unknown component type in the current configuration tree. This can only result from revision mismatch between the ruleset and console firmware. %GCU-E-NOIFUNCTION, Unknown internal function The user has modified the ruleset file and specified an unknown internal GCU function. Correct the ruleset or download a new one from the OpenVMS Galaxy web page. %GCU-E-NOEFUNCTION, Missing external function The user has modified the ruleset file and specified an unknown external function. Correct the ruleset or download a new one from the OpenVMS Galaxy web page. %GCU-E-NOCFUNCTION, Missing command function The user has modified the ruleset file and specified an unknown command procedure. Correct the ruleset or download a new one from the OpenVMS Galaxy web page. %GCU-E-UNKNOWN_COMPONENT: {component} The GCU has parsed an unknown component. This can result from ruleset corruption or revision mismatch between the ruleset and console firmware. %GCU-E-BADPROP, Invalid ruleset DEVICE property The GCU has parsed an invalid ruleset component statement. This can only result from ruleset corruption. Download a new one from the OpenVMS Galaxy web page. %GCU-E-BADPROP, Invalid ruleset CHART property The GCU has parsed an invalid chart statement. This can only result from ruleset corruption. Download a new one from the OpenVMS Galaxy web page. %GCU-E-BADPROP, Invalid ruleset INTERCONNECT property The GCU has parsed an invalid ruleset interconnect statement. This can only result from ruleset corruption. Download a new one from the OpenVMS Galaxy web page. %GCU-E-INTERNAL Slot {slot detail} The GCU has encountered an invalid datatype from a component parameter. This can result from ruleset or model corruption. Download a new one from the OpenVMS Galaxy web page. If the problem persists, delete and recreate the offending model. %GCU-F-PARSERR, {detail} The GCU encountered a fatal error while parsing the ruleset. Download a new one from the OpenVMS Galaxy web page. %GCU-W-NOLOADFONT: Unable to load font: {font} The GCU could not locate the specified font on the current system. A default font will be used instead. %GCU-W-NOCOLORCELL: Unable to allocate color The GCU is unable to access a colormap entry. This can result from a system with limited color support or from having an excessive number of graphical applications open at the same time. GCU-E-NOGALAXY, This system is not configured as a Galaxy. Description: The user has issued the CONFIGURE GALAXY/ENGAGE command on a system which is not configured for Galaxy operation. User Action: Configure your system for Galaxy operation using the procedures described in the OpenVMS Galaxy Guide. If you only want to run a single-instance Galaxy, enter CONFIGURE GALAXY without the /ENGAGE qualifier and follow the instructions provided by the Galaxy Configuration Utility. %GCU-E-ACTIONNOTALPHA GCU actions require OpenVMS Alpha A GCU user has attempted to invoke a Galaxy configuration operation on an OpenVMS VAX system. %GCU-I-ACTIONBEGIN at {time}, on {instance} {mode} This informational message indicates the start of a configuration action on the specified Galaxy instance. Note that many actions require collaboration between command environments on two separate Galaxy instances, thus, you may encounter two of these messages, one per instance involved in the operation. The mode argument indicates which instance is local versus remote. %GCU-S-ACTIONEND at {time}, on {nodename} This is the normal successful completion message following a Galaxy configuration action. Note that many actions require collaboration between command environments on two separate Galaxy instances, thus, you may encounter two of these messages, one per instance involved in the operation. %GCU-S-ACTIONEND, Exiting GCU$ACTIONS on ^Y Indicates that the user has aborted a Galaxy configuration action using Control-Y. %GCU-S-ACTIONEND, Exiting GCU$ACTIONS on error {message} Indicates that a Galaxy configuration action terminated with error status as indicated by the message argument. %GCU-E-ACTIONUNKNOWN no action specified Indicates that the GCU$ACTIONS.COM procedure was called improperly. It is possible that the command procedure has been corrupted or is out of revision for the current system. %GCU-E-ACTIONNOSIN no source instance name specified Indicates that the GCU$ACTIONS.COM procedure was called improperly. It is possible that the command procedure has been corrupted or is out of revision for the current system. %GCU-E-ACTIONBAD failed to execute the specfied action Indicates that a Galaxy configuration action aborted due to an indeterminate error condition. Review related screen messages and verify that the necessary proxy accounts have been established. %GCU-E-INSFPRIVS, Insufficient privileges for attempted operation An underprivileged user has attempted to perform a Galaxy configuration action. Typically, these actions are performed from within the system managers account. OPER and SYSPRV privileges are required. %GCU-E-NCF network connect to {instance} failed An error has occurred trying to open a DECnet task-to-task connection between the current and specified instances. Review related screen messages and verify that the necessary proxy accounts have been established.

OpenVMS supports several methods of managing CPU resources. The console establishes the default owner instance for each CPU using the console environment variables. This allows the CPU resources to be statically assigned, providing a precise initial configuration. In the event of a cold boot (that is, power cycle or initialization), this default configuration is restored from console nonvolatile RAM.

Once a configuration has been booted, OpenVMS provides more elegant means of assigning resources for users with CMKRNL (Change Mode to Kernel) privilege. The following sections describe these methods.

12.1 DCL Reassignment

Users with CMKRNL privilege can perform CPU reassignment operations using the following DCL command:

$ STOP/CPU/MIGRATE=instance-or-id cpu-id

The user must provide the target instance name (SCSNAME) or numeric ID (0, 1, and so on), and the numeric ID of the CPU being reassigned. The following examples show a few forms of this command.

$ STOP/CPU/MIGRATE=0 4 !Reassign CPU 4 to instance 0 $ STOP/CPU/MIGRATE=1 3,4,5 !Reassign CPUs 3,4,5 to instance 1 $ STOP/CPU 7/MIGRATE=BIGBNG !ReassignCPU 7 to instance BIGBNG $ STOP/CPU/ALL/MIGRATE=0 !Reassign all secondary CPUs to instance 0

These commands can be inserted into command procedures. For example, you might want to move extra CPU resources to an instance in a startup procedure of an application with known processing requirements. Similarly, you may want to reassign CPUs away from an instance that is about to perform lengthy, I/O intensive operations (such as backups) so that the CPUs are available to other instances. When the job completes, you may reassign them back. Or you may reassign CPUs away from an instance that is shutting down.

Note that you can only reassign resources away from an instance. This is the push model defined by the Galaxy Software Architecture. This model prevents resources from being "stolen" by other instances that may not be aware of their current usage. To effectively manage the entire Galaxy system using DCL, you must either log in to each of the involved instances or use the SYSMAN utility to execute the commands on the owner instance.

12.2 GCU Drag-and-Drop Reassignment

The GCU provides an interactive visual interface for managing Galaxy resources. Using the GCU, you can reassign CPUs by simply dragging and dropping them among instances. Additionally, the GCU allows you to draw charts of various configurations (known as configuration models), and save them as files. At any time, you can load and engage a configuration model and the system will reassign resources as needed to achieve the desired model.

12.3 Intermodal Reassignment

Because of the resource push model defined by the Galaxy Software Architecture, resources must be given away by the Galaxy instance that currently owns them. For a utility or user to effectively manage resource assignment in a multiple-instance Galaxy configuration, you must establish some means of executing commands on each instance.

One such means is to open a window or terminal session on each of the Galaxy instances and perform your resource management operations in each of these windows.

Another method is use the SYSMAN utility and its underlying SMI-Server to establish a command environment on the owner instance. Using this method, a fairly simple command procedure can be written to perform specific resource management operations. This method has some limitations, however. First, it requires that the involved Galaxy instances must be in a cluster. Also, a command procedure cannot effectively pass variable parameters to SYSMAN environment scripts, and you cannot specify a remote system password within a SYSMAN script. So it is cumbersome to generate a general-purpose command procedure interface that uses SYSMAN.

The GCU does, in fact, use SYSMAN wherever possible to accomplish its management actions. When a system is not configured to support SYSMAN, the GCU will attempt to use DECnet task-to-task comminations among proxy accounts as its management transport. If that approach also fails (that is, if the system is not running DECnet or if the necessary proxy accounts are not set up), the GCU will not be able to manage Galaxy instances other than the one on which the GCU is currently running. You could certainly run multiple copies of the GCU if you choose, one per Galaxy instance. However, you can assume that OpenVMS Galaxy systems are likely to be clustered or to use DECnet.

The GCUs management actions are based in the SYS$MANAGER:GCU$ACTIONS.COM command procedure. You can modify this file to customize actions for your own environment. For example, in a TCP/IP environment, you may choose to use REXEC or a similar utility for your management transport, or you may want to include some form of notification or logging whenever a management action is executed.

The GCU$ACTIONS.COM file is somewhat unusual in the way it operates. When using SYSMAN, the procedure builds small SYSMAN command scripts in temporary files to deal with variable parameters that SYSMAN cannot handle. When SYSMAN is not available, the procedure attempts to open a DECnet task-to-task connection to a proxy account on the owner instance. If successful, it uses this connection to shuffle command parameters to the copy of GCU$ACTIONS.COM that resides on the owner instance. The end result is execution of the command locally by the owner instance.

	privacy and legal statement
6512PRO_007.HTML