9.2  Managing an OpenVMS Galaxy with the GCU

  Your ability to manage a Galaxy system using the Galaxy
  Configuration Utility (GCU) depends on the capabilities of
  each instance involved in a management operation.

  The GCU can be run from any instance in the Galaxy.

  However, the Galaxy Software Architecture implements a
  push-model for resource reassignment.  This means that, in
  order to reassign a processor, you must execute the reassign
  command function on the instance that currently owns the
  processor.  The GCU is aware of this requirement, and will
  attempt to use one or more communications paths to send
  the reassignment request to the owner instance.  DCL is not
  inherently aware of this requirement; therefore, if you use
  DCL to reassign resources, you will need to use SYSMAN or
  a separately logged-in terminal to issue the commands on
  the owner instance.

  The GCU favors using SYSMAN, and its underlying SMI_
  Server processes to provide command paths to the other in-
  stances in the Galaxy.  However, the SMI_Server requires
  that the instances be in a cluster so that the command envi-
  ronment falls within a common security domain.  However,

  Galaxy instances might not be clustered.

  If the system cannot provide a suitable command path
  for the SMI_Server to use, the GCU will attempt to use
  DECnet task-to-task communications.  This requires that
  the participating instances be running DECnet, and that each
  participating Galaxy instance have a proxy set up for the
  SYSTEM account.

  It is possible for an instance to not be clustered, have no
  proxy account established, and not have DECnet capability.
  These are considered isolated instance from a management
  perspective.  The only way to reassign resources from an
  isolated instance is to be logged in to its console.  (For more
  information about isolated instances, see  Section 9.2.1.)

  9.2.1  Independent Instances
  You can partition a Galaxy system so that one or more
  partitions are booted without becoming members of the

  Galaxy sharing community.  These are known as indepen-
  dent instances.  Because independent instances reside in a
  Galaxy partition, their presence is reflected in the Galaxy

  Configuration File, and they are visible to the GCU.

  These independent they can still participate in CPU reas-
  signment.  They cannot utilize shared memory or related
  services.

  You can create a partition that has no Ethernet device and
  is not a member of a cluster or of the Galaxy sharing com-
  munity.  These are known as    isolated instances    .  Because
  they reside in a Galaxy partition, they are still visible to the
  GCU and you can reassign CPUs to them.  To reassign CPUs
  away from isolated instances, you must log in to the console
  of the isolated instance.

  9.2.2  Required PROXY Access

  When the GCU needs to execute a management action, it
  always attempts to use the SYSMAN utility first.  SYSMAN
  requires that the involved instances be in the same cluster.  If
  this is not the case, the GCU will next attempt to use DECnet
  task-to-task communications.  For this to work, the in-
  volved instances must each have an Ethernet device, DECnet
  capability, and suitable proxy access on the target instance.

  For example, consider a two-instance configuration that is
  not clustered.  If instance 0 were running the GCU and the
  user attempts to reassign a CPU from instance 1 to instance

  0, the actual reassignment command must be executed on
  instance 1.  To do this, the GCU's action procedures in the file
  SYS$MANAGER:GCU$ACTIONS.COM will attempt to es-
  tablish a DECnet task-to-task connection to the SYSTEM
  account on instance 1.  This requires that instance 1 has
  granted proxy access to the SYSTEM account of instance

  0.  Using the established connection, the action procedure on
  instance 0 will pass its parameters to the equivalent action
  procedure on instance 1, which now treats the operation as a
  local operation.

  The GCU action procedures assume that they will be used
  by the system manager.  Thus, in the action procedure file
  SYS$MANAGER:GCU$ACTIONS.COM, the SYSTEM ac-
  count is used.  To grant access to the opposite instances

  SYSTEM account, the proxy must be set up on instance 1.

  To establish proxy access:

  1.  Enter the following commands at the DCL prompt:

      $  SET  DEFAULT  SYS$SYSTEM
      $  RUN  AUTHORIZE

  2.  If proxy processing is not yet enabled, enable it by entering
      the following commands:

      UAF>  CREATE/PROXY
      UAF>  ADD  PROXY  instance::SYSTEM  SYSTEM
      UAF>  EXIT

  Replace  instance with the name of the instance to which you
  are granting access.  Perform these steps for each of the in-
  stances you want to manage from the instance on which you
  run the GCU. For example, in a typical two-instance Galaxy,
  if you run the GCU only on instance 0, then you need to add
  proxy access only on instance 1 for instance 0.  If you in-
  tend to run the GCU on instance 1 also, then you need to add
  proxy access on instance 0 for instance 1.  In three-instance
  Galaxy systems, you may need to add proxy access for each
  combination of instances you want to control.  For this reason,
  a good rule of thumb is to always run the GCU from instance
  0.

  You are not required to use the SYSTEM account.  To change
  the account, you need to edit SYS$MANAGER:GCU$ACTIONS.COM
  on each involved instance.  Locate the line that establishes the
  task-to-task connection, and replace the SYSTEM account
  name with one of your choosing.

  Note that the selected account must have OPER, SYSPRV,
  and CMKRNL privileges.  You also need to add the necessary
  proxy access to your instances for this account.