%dcl-e-open

[Willem Grooters]

From your last output:

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 can never(?) be a socket device so checking on UCX/TCPIP has no meaning. I would advise to relabel the disk to something less ambiguous, If possible and feasible (because it may require changes in procedure and software)

[Hoff]

>>> %DCL-E-OPENOUT, error opening BG_DIGI:[LOGIN] LAST_SETUP_DIGI.COM; as output
-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.

[Jon Pinkley]

If you don't have a good backup of the DKB0 drive, and it has critical data that can't be recovered from a backup tape, then I would recommend shutting down, booting from the installation CD, and doing a PHYSICAL backup of the DKB0 device. After that works, then an IMAGE backup. The output of the analyze shows there are areas of the disks that can no longer be read, and I am not confident that an IMAGE backup will be able to save as much (possibly recoverable) data as a PHYSICAL backup will. A Physical backup will also in general put less stress on the drive, as it is just a LBN by LBN copy.

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

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1191154

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.

Jon

[Hoff]

>>>if you backup without /ignore=interlock and get no warning messages, then you do have a reasonable guarantee that the backup is consistent.

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.

[Jon Pinkley]

I made no claim about a backup /ignore=interlock being guaranteed correct if there were no warnings. I was talking about "without /ignore=interlock".

However, I have not been able to reproduce the "silent corruption scenario", but that does not mean it isn't possible.

Jon

[Richard J Maher]

Hi Steve,

[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

[Hein van den Heuvel]

Hmm,

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,"

fwiw,
Hein.