skip book previous and next navigation links
go up to top of book: HP OpenVMS Alpha Partitioning and Galaxy Guide HP OpenVMS Alpha Partitioning and Galaxy Guide
go to beginning of chapter: CPU Reassignment at the DCL CLI CPU Reassignment at the DCL CLI
go to previous page: GCU Drag-and-Drop Reassignment GCU Drag-and-Drop Reassignment
go to next page: Software Reassignment Using Galaxy ServicesSoftware Reassignment Using Galaxy Services
end of book navigation links

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, you can write a fairly simple command procedure 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. Therefore, 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 attempts to use DECnet task-to-task communications 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 is not able to manage Galaxy instances other than the one on which the GCU is currently running. You can 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.


go to previous page: GCU Drag-and-Drop Reassignment GCU Drag-and-Drop Reassignment
go to next page: Software Reassignment Using Galaxy ServicesSoftware Reassignment Using Galaxy Services