Yes, we've had several incidents similar to this where the RC was unable to specifically point to a device/cable/DA/etc. as the culprit. Occasionally, our local office has "shotgunned" fixes - i.e., blindly replaced components outside the disk mech itself (you didn't state what model disk drive was involved) - even replacing the servo and read/write controllers on the drive. Occasionally, however - especially with our older Eagles (793x/FL) - the mech has had to be replaced after all other attempts to fix the problem failed, but (and this is outside the scope of your question, but I have to mention it!) we've avoided system or volumeset reloads by using DTDUTIL via SYSDIAG to snap the data off the disk to tape, first, then reloading the data back to the drive after the mech was replaced. This won't work on LDEV1 (I also don't know if SCSI devices are supported - ours are all HP-FL) and it's doubtful in the event of a head crash or other physical media damage. Also, the system must be started in single-user, single-disk mode. This has saved us hours of reloading and recovering data and databases!! I'd recommend that you talk to your CE or other knowledgeable support person about this utility. If it's not on your system, ask HP for it!! Good luck! ======================================================================= Lee Gunter Voice: 503-375-4498 HMO Oregon FAX: 503-588-4350 PO Box 12625 E-Mail: [log in to unmask] Salem, OR 97309 USA Private E-Mail: [log in to unmask] ======================================================================= The opinions expressed, here, are mine and mine alone, and do not necessarily reflect those of my employer. ______________________________ Reply Separator _________________________________ Subject: System Never Came Back from dinner Author: [log in to unmask] at ~INTERNET Date: 12/7/95 6:36 PM Last night I was not able to dial in to our HP3000 967/RX Mpe/ix 5.0. I thought that our modem wan hung and decided to come in a couple of hours earlier this morning and perhaps reset the modems and DTC's before the users began logging on. To my surprise I discovered that the system was hung and would not reply to my attempts of logging on. The only input from the console that I could manage were Cntl A and Cntl B. The console indicators as well as the lights on the CPU indicated that the machine was running but the last message on the console was from 22:12 and the fact that the DAT tape had not been ejected indicated that the backup had not been performed. So I went through the Cntl B /TC sequence started the memory dump and called HPRC. They indicated that they would be logging on to check the dump and I proceeded to reset and reboot the system. The system was in operational condition before the users began logging on, but we had to restart some jobs that did not get to finish. Some hours later the HPRC called back saying that the dump indicated that ldev 37 was the reason for the hang and were considering to replace it although no errors were logged against that device and no errors were detected when they 'exercised' the device. Since we were hesitant to halt our production and thus loose today's data entry and all of the recovery work, the HPRC disk specialists and dump analysts had another huddle and decided that the situation did not warrant changing the ldev. They indicated that while they were 100% sure that actions involving ldev 37 were the reason for the hang, they had no idea what the initial cause was nor could they rule out the possibility that it was software. The potential list included: a bad controller, bad cable, bad scsi terminator, intermittent power supply, faulty scsi driver, etc..... While I feel better dumping all this here, I also have that sinking feeling that this thing will occur again and perhaps at an even more critical situation. Has anyone else out there had anything similar? Did it reoccur? Was it ever resolved? etc? ... ? Thanks Paul H. Christidis