Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!TAMSIGMA.BITNET!ALW6944
From: ALW6944@TAMSIGMA.BITNET.UUCP
Newsgroups: comp.os.vms
Subject: ANALYZEing after Crash on VAXcluster
Message-ID: <8711010108.AA29826@ucbvax.Berkeley.EDU>
Date: Wed, 28-Oct-87 09:44:00 EST
Article-I.D.: ucbvax.8711010108.AA29826
Posted: Wed Oct 28 09:44:00 1987
Date-Received: Tue, 3-Nov-87 01:30:38 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 24

I would like some suggestions from VAXcluster managers out there in netland. We
have a VAXcluster consisting of VAX 8300/8650/8800 running VMS V4.6. In the
past when one of the systems would crash, we would suspend all batch jobs,
knock off the interactive users, and begin an ANALYZE/DISK to check for any
errors.  Occasionally this has uncovered a few minor problems, but nothing too
serious that we couldn't have continued normal operation.

The problem?  With 6 RA81s bound into a volume set, this process takes quite
some time.  The users naturally are irritated by all this -- after all,
a VAXcluster is supposed to offer redundancy, and allow continued operation
even when one VAX dies, right?  We, i.e. operations, just hem and haw at this
point and say "yeah, but...".

We will probably discontinue ANALYZEing after a system crash, but would
appreciate input from other managers.

                                     ThaADVANCEnks,
                                     Lee

------------------------------------------------------------------------------
                      A. Lee Wade    409 845-9641
    Engineering Computer Services    ALW6944@TAMSIGMA.BITNET
           Texas A & M University    UTSPAN::UTADNX::SIGMA::ALW6944  (SPAN)
College Station, Texas 77843-3154