Tom asks:

> Although everything I read says your must INSTALL to swap out a bad
> disk drive  on MPEIX 5.0 I still wonder if you could

> a) stop all processes on system
> b) Move all files off the bad drive (identifying them using
>    the VOLUTIL SHOWUSAGE MPEXL_SYSTEM_VOLUME_SET)
> c) Set transient allocation to 0, perm = 100
> d) reboot system (possibly single user mode)
> e) VOLUTIL SCRATCHVOL MPEXL_SYSTEM_VOLUME_SET:MEMBERBAD
>    (I am guessing this may be the command that will not work)
> f) SHUTDOWN SYSTEM
> g) replace bad drive
> h) bring up system and add the new drive back in.

Well, you can't remove a disk from a volume set ... so step (e) would
probably not work.

If the disk drive is marginal, but generally working, you could do:

   1) configure a new disk drive of same size (i.e., a replacement drive)
      on the bus with a new ldev ('31' for example)
      (let's assume the bad ldev is ldev 30)
      (let's save that new system configuration in the gruop NEWDRIVE)

   2) shutdown, connect new drive, bootup (START NORECOVERY GROUP=NEWDRIVE)
      in single user mode.

   3) MAKE SURE NO JOBS OR SESSIONS ARE RUNNING (except your console session)

      <plug>
      run defragx.pub.lps
      clone 30 to 31
      </plug>

      When CLONE is done, *IMMEDIATELY* shut off the power to the computer
      (i.e., *don't* do a =SHUTDOWN ... simply turn off the power!!)

      OR:

      Use the offline diagnostics to do a diskcopy (free, but harder to
      use) of ldev 30 to ldev 31.
      and, when done, power off machine.

   4) uncable old drive (was ldev 30)

   5) (optional) change ID on new drive (was ldev 31) to be the
      same ID as old ldev 30 (assuming both are on same SCSI or HPIB chain)

   6) turn power on & bootup.

Essentially, cloning the existing drive will probably work, but the
probability of it working drops rapidly the longer you wait between
the end of the cloning process and the turning off of power.  It also
drops even more rapidly if you are doing work of any kind on the system
during the cloning.  Why?  Because any disk activity that updates data
on ldev 30 (the 'source' drive) has a 50/50 chance of being written to
ldev 30 below the point where the cloning process has already read from
the disk ... yet there are data structures on other disk drives that
rely on the fact that the data was written, even though it didn't get
cloned to the new drive.

This process has been done twice that I'm aware of (once in New Zealand,
once in Oregon (?)), and worked both times ... nevertheless, I usually
recommend a reload (INSTALL) afterwards ... I'm cautious!  In both cases the
users *really* wanted to get a workable system up so they could do
a full backup before reloading.


--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html