[Info-vax] : One last backup

[Steven Schweda]

On Dec 1, 8:32 am, Art <awi... at postmedia.com> wrote:

> [...]  What I am concerned about is the queue manager.  How
> do I avoid the old system (with it's existing queue database)
> from participating in / messing up the existing Queue scheme?
> Delete the old legacy database before joining?

   My experience may or may not be relevant here, but I have
a collection of transient cluster members -- seldom used
systems, with VMS new enough to join my main-system cluster
(which normally comprises only my main Alpha XP1000 system).
These transient systems are generally configured with zero
votes (so that their coming and going doesn't greatly bother
the main system).  Each has its own system disk.  (UAF data
are roughly compatible, but not actually shared.)  Each of
the transient systems uses the cluster-wide queue manager, so
it has something like this in its SYS$MANAGER:SYLOGICALS.COM:

$ DEFINE /SYSTEM /EXECUTIVE_MODE QMAN$MASTER ALP$DKC0:[QMAN]

while on ALP (the main system) itself, it's:

$ DEFINE /SYSTEM /EXECUTIVE_MODE QMAN$MASTER SYS$SYSDEVICE:[QMAN]

(and ALP's SYS$SYSDEVICE is ALP$DKC0 these days).

   When all the secondary systems are down, "SHOW QUEUE
/BATCH /ALL" might say something like this:

alp $ sqba
Batch queue SETI$BATCH_ALP, idle, on ALP::

Batch queue SYS$BATCH_ALP, available, on ALP::

  Entry  Jobname         Username             Status
  -----  -------         --------             ------
    979  CWU1_SUB        SYSTEM               Executing
    981  RUN_DTSS_NTP    SYSTEM               Executing
    221  WWW_TEST        SYSTEM               Holding until  1-
DEC-2011 13:56:14
    222  WWW_FLUSH       SYSTEM               Holding until  1-
DEC-2011 14:03:17
    188  DAILY           SYSTEM               Holding until  2-
DEC-2011 00:10:00

Batch queue SYS$BATCH_ALP2, stopped, autostart, on ALP2::

Batch queue SYS$BATCH_IT, stopped, autostart, on IT::

  Entry  Jobname         Username             Status
  -----  -------         --------             ------
    823  DAILY           SYSTEM               Pending

Batch queue SYS$BATCH_REX, stopped, autostart, on REX::

Batch queue SYS$BATCH_WEAK, stopped, autostart, on WEAK::

Batch queue SYS$BATCH_WUSS, stopped, autostart, on WUSS::
alp $

   When, say, IT comes up, its section might look like this:

Batch queue SYS$BATCH_IT, idle, on IT::

  Entry  Jobname         Username             Status
  -----  -------         --------             ------
    226  DAILY           SYSTEM               Holding until  2-
DEC-2011 00:10:00

   So, these transient systems participate in, but don't
really mess up, "the existing Queue scheme".

   My system start-up procedures deal with the fact that the
usual queue-manager start command(s) will fail, because the
remote queue-manager data base is unavailable until the
remote disks are mounted.  They do the remote disk mounting,
and then try (again) to:
      START /QUEUE /MANAGER
and
      ENABLE AUTOSTART /QUEUES

Not too classy, but it seems to work.

   If the transient systems are reasonably well behaved, they
seem to be able to come and go without causing any real
trouble for the cluster-wide queue manager.  I don't bother,
but I assume that all of those transient-system jobs and
queues can be deleted even when the "on" system is absent
from the cluster.  Look.  There goes one now:

alp $ del /ent = 226
alp $ sqba
[...]
Batch queue SYS$BATCH_IT, stopped, autostart, on IT::

Batch queue SYS$BATCH_REX, stopped, autostart, on REX::
[...]

   What could go wrong?