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.