I'd agree with Bill! We had a similar problem a few months ago and it involved a 12H
array. It WAS the MIRVUTIL that was the problem. The response center had us back
up and running within a few minutes.

Cynthia Bridges-Fowler
HP3000 Senior System Administrator
North American Salt Company
a division of Compass Minerals Group
[log in to unmask]
http://www.compassminerals.com/    

>>> Bill Cadier <[log in to unmask]> 07/23/03 03:41PM >>>
David writes:

> I added a second 12h disc array to our 997 system (OS 6.5 pp2 + reactive as
> of 2/14/03)last night. We added the the paths and ldevs with no problems.
> Mapper identifed the devices as we configured them in sysgen. No Problem.
> dstat all reported ldevs 14-19 as unknown. While in volutil, I executed the
> newvol fmmtx_set:member3 14 100 100 to add the drive to a private volume
> set. The console reported as follows:  dismount request for ldev 14 granted
> (avr 11) begin volume mounting of fmmtx_set:member3 (ldev 14) (avr 8)
> fmmtx_set volume mounted on ldev 14 (avr 11)       system abort 2559 from
> subsystem 99  compatibility mode suddendeath 311 system halt 7, $09ff    We
> Ctrl-B the system back up and ldev14 reported as the member3 in the private
> volume set. I added ldev 15 with volutil and the same error message came
> up. Broght the system back from the halt and 15 shows up. We've been
> running fine for the last 12 hours now. Can some one tell me what may have
> caused the system halt 7 when I added the drive.

The SA2559 CM SF 311 is a compatibility mode failure and it looks similar to the
description of a problem found in one of our service requests 8606-224012 . The
reported cause of the abort is running an older version of Mirvutil (actually Volutil)
than should be there.

I would highly recommend that you contact the Response Center or whoever provides
your software support for assistance and to confirm that this is the problem.

A quick check you can perform is to do

:LISTFILE MIRVUTIL.PUB.SYS,2

According to SR 8606-224012 the best way to determine which version of mirvutil you
have is to check the EOF since the version will always say A.01.00. Here's a table
documented in the SR:

 Op.Sys./Patch Level           EOF       MIRVUTIL Version
 -------------------          ----       ----------------
  Base MPE/iX 6.0             1993           A.01.00
  6.0, MPELX81A               1993           A.01.00
  Base MPE/iX 6.5             2035           A.01.00
  6.5, MPELX81B               2051           A.01.00
  Base MPE/iX 7.0             2034           A.01.00

hth,

Bill
hp/vCSY

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *