- Integrated Systems
- About Us
- Integrated Systems
- About Us
10-09-2008 03:32 AM
LITAX1$DKB0: Mounted 9 DISK2 5630778 2 1
9 = error count.
Since you had errors on that disk before, and now nine errors since reboot, I wouldn't trust the disk too much and replace the disk ASAP. Keep a close watch on the error count. If it rushes up, you're too late to salvage any data from it.
In general: if a device is locked for write and you KNOW it's not mounted 'readonly', always check the device for errors, and have a look to the error log.
BTW: "BG" is a socket device, when follwoed by a NUMBER. BG
OpenVMS Developer & System Manager
10-09-2008 08:14 AM
-RMS-E-WLK, device currently locked
That error is very likely from a failed OPEN command and -- no matter what the target OPEN specification might be -- a DCL OPEN command isn't connected to IP nor to the BG port devices in any meaningful fashion in any available OpenVMS release. I'd expect that the AUXS failure message is a bit of a canard, and due to the error not being fielded correctly by the connection; that the DCL error is being reflected and shown in the context of the IP processing or the IP tear-down.
To the OP: confirm your disk archive (BACKUP /IMAGE) is good and current and get a copy of anything you care about copied off this disk. Get set to swap the disk for a replacement. And look at the other disks, since I'm going to bet this box is ancient; once one disk goes, others tend not to be far behind.
Confirm that somebody that set up the local archival strategy did NOT use a BACKUP /IMAGE /IGNORE=INTERLOCK; that command sequence is both common and it won't necessarily get you a complete and consistent copy of your disk data. Or just go get yourself a current BACKUP /IMAGE of the disk now.
And one final caveat: the more you put load on a failing disk and the longer you wait, the more likely you'll increase the errors or to completely fail. Placing an I/O load on a disk with an ANALYZE operation and such is *not* an approach I'd suggest with a failing disk -- not until *after* you have your data off the disk, since a full-disk BACKUP will itself put substantial I/O load on the disk. And might well fail.
10-09-2008 02:45 PM
Since this isn't the system disk, you could possibly do the backup without booting from the CD, but unless you can mount the disk privately, you will not be guaranteed to get a good IMAGE backup. If you follow Hoff recommendation and use
$ backup/image dkb0: tape: ...
without the /ignore=interlock, any file that is open for write will just be skipped. If you do use /ignore=interlock you won't be guaranteed that those files are backed up correctly, but in my opinion, a backup /ignore=interlock is better than a backup without /ignore=interlock if you are making a backup of a disk that is mounted for shared write access.
If you backup without /ignore=interlock and get no warning messages, then you do have a reasonable guarantee that the backup is consistent. But if you do get any warning messages, then your backup is definitely incomplete if you did not specify /ignore=interlock.
If you are interested, see
Which has both sides of the argument.
On the other hand, if this is just a scratch drive with unimportant files, then it probably isn't work spending the time to try to recover, which will be a very time consuming and therefore expensive operation, without any guarantees of usable results. By far the simplest is to put in a replacement (used) RZ29 and restore from a recent backup.
10-09-2008 04:44 PM
That's actually not the case, interestingly enough. Shutting off the interlocks can permit entirely silent corruptions in the output saveset or output copy; that detail was from a direct discussion with one of the engineering folks that was maintaining BACKUP itself, too.
10-10-2008 02:00 AM
However, I have not been able to reproduce the "silent corruption scenario", but that does not mean it isn't possible.
10-11-2008 06:38 PM
[That error is very likely from a failed OPEN command and -- no matter what the target OPEN specification might be -- a DCL OPEN command isn't connected to IP nor to the BG port devices in any meaningful fashion in any available OpenVMS release. ]
What about an INETd server that does: -
$open/read/write socket sys$net
[I'd expect that the AUXS failure message is a bit of a canard, and due to the error not being fielded correctly by the connection; that the DCL error is being reflected and shown in the context of the IP processing or the IP tear-down.]
I reakon you're right.
Cheers Richard Maher
10-12-2008 04:55 AM
I don't understand where the last series of reiplies come from. I thought it was established that the target disk was bad (partiry errors) and that the system effectivly write-locked the drive.
According to an earlier attachment, the devices status includes: "allocation inhibited because of error on bitmap,"