9.7 CPU Reassignment OpenVMS supports several methods of managing CPU re- sources. 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. 9.7.1 DCL Reassignment Users with CMKRNL privilege can perform CPU reassign- ment 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 in to 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 per- form 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 in- volved instances or use the SYSMAN utility to execute the commands on the owner instance. 9.7.2 GCU Drag-and-Drop Reassignment The GCU provides an interactive visual interface for man- aging Galaxy resources. Using the GCU, you can reassign CPUs by simply dragging and dropping them among in- stances. 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. 9.7.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 util- ity 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 under- lying SMI-Server to establish a command environment on the owner instance. Using this method, a fairly simple com- mand procedure can be written to perform specific resource management operations. This method has some limitations, however. Firts, it requires that the involved Galaxy instances must be in a cluster. Also, a command procedure cannot ef- fectively 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 multi- ple 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 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 at- tempts 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. 9.7.4 Software Reassignment Using Galaxy Services Perhaps the best method for managing resource assignment is to use the Galaxy APIs to write your own resource man- agement routines. This allows you to base your decisions for resource management on your own criteria and application environment. The same push-model restriction described in Section 9.7.3still exists, however, so your routines will need to be Galaxy aware, possibly using shared memory to coordinate their operations. For information about CPU reassignment APIs, see Chapter 16. 9.7.5 Reassignment Faults CPU reassignment can fail or be blocked, for several rea- sons. Because the GCU buries its management actions in SYSMAN or DCL scripts, it may not always identify and re- port the reasons for a reassignment fault. The GCU does perform certain checks prior to allowing reassignment ac- tions in order, for example, to prevent attempts to reassign the primary CPU. Other reasons exist for reassignment faults that can only be detected by the operating system or console firmware. For example, if the operating system de- tects a fault attempting to reassign a CPU that currently has process affinity or Fast Path duties, a DCL message will be displayed on both the console and the users terminal. The Galaxy APIs for reassignment are capable of reporting most faults to the caller. However, even using the reassign- ment services, the console may reject a reassignment because of hardware platform dependencies not readily visible to the operating system.