David writes:
>
>   System Abort 1101 from Subsystem 101

Hmmm...1101 is:

'An error occurred while low-level I/O atempted to READ a NATIVE MODE stack
page in from secondary storage.'

>   Secondary Status:  info=-44, subsys=113

#113 is "Low Level I/O", a group that broke the HP internal rules on
how to report errors, with the result that you can't just use Debug's
"errmsg" to convert (-#44, -#113) into "english" :(

> They feel it is a bad disk drive.   :-(   :-(   :-(   :-(  Which is a

I'd agree.

> HP is supposed to arrive in the morning to check/replace the drive.
> That will presumably resolve the problem.  One problem though... The
> data that was stored on LDev 3!  Is there any way to
> identify/retrieve any of that data?  (DiscUtil doesn't recognize the
> drive, so it was no help - unless the HPRC didn't know what he was
> doing.)

Can you boot up at all?  If yes, try an immediate run of VOLUTIL to
change the PERM and TRAN percentage on ldev 3 to 0, to prevent any more
files (or transient space) being allocated on it.

Can you boot up by doing:

   1) power off ldev 3;
   2) bootup

> - Any existing database should not be effected because it would have
> been on one of the old drives. (Dynamic expansion is off.)

probably true.  There's some chance that the image control file ("GB")
was allocated on that drive when you opened the database after adding the
drive ... but I don't know what the unavailability of that file would
do at recovery time.

> -  Any existing file that was not changed should not be effected
> because it would have been on one of the old drives.

true.

> -  Any file that was changed, but not in such a way that a new
> extent was required, will most likely not be effected since it would
> have been on one of the old drives.

true

> -  Any new file will most likely be effected since it likely went on
> LDev 3.

true...unless you used Lund's De-Frag/X or Bradmark's product to balance the
drives.  (I guess that's a partial plug :)

> -  Any file that was changed such that a new extent was required will
> most likely be effected since it likely created the new extent on
> LDev 3.

true, unless the file was marked as "ldev 1 only" (or similar allocation
restriction).

> If I can identify the effected files somehow, I can restore them from
> this morning's tape, and just have lost today's updates on those
> files.  But how do I know what ones I have to restore?  If I have to
> restore the entire system from this morning's tape, I'll loose _all_
> of today's updates.  Or is there some way around this that I'm not
> seeing?

One possibility is to hook up a FOURTH drive, of identical capacity to
the bad drive, and do an online or offline copy from the bad drive to
the fourth drive (assuming, of course, that the bad drive is good enough
to permit this).  Then, turn off power (don't do a formal shutdown if the
system was up), unplug the bad drive, change the ID of the fourth drive to
match the old ldev 3 (SCSI or HPIB), and reboot ...
there's a *CHANCE* that this will result in a fully recovered system  ...
if no valuable part of the bad LDEV 3 was unreadable.

The ODE utility can do such an offline copy, and <plug> De-Frag/X </plug>
can do an on-line copy.  (Hey, offline's easier, if ODE will cooperate!)

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