Tape Drive in Mount Verification

[Michael Hogarty]

VMS 7.2-1 using a TL891 library.

I've run into the annoying situation of a tape drive going into mount verification, the allocating process is dead, and I can't get mount verify to cancel. I've tried the suggestions in the System Management manual to no avail. These were dismount/abort, waiting for TAPE_MVTIMEOUT and using IPC from the console to cancel the verification.

I've resigned myself to rebooting the system now, but I was wondering if there is really no other way around this? Seems like this has been a problem since 1985, at least.

[Phil.Howell]

I think the last resort before you reboot is to power off/on the tape library.
Phil

[Antoniov.]

Micheal,
did you try follow before reboot?
$ DISM/OVER=CHECK

Antonio Vigliotti

[Ian Miller.]

is the tape drive allocated to a process that does not exist?

[Michael Hogarty]

I did not try DISM /OVER=CHECKS (thought that was only relevant to disks), but when I tried with /ABORT it told me device not mounted, so I wasn't very hopeful.

I also did not power down the library; maybe worth a try next time.

Ian, yes, the tape drive is allocated to a process that does not exist.

As an update, what I am doing is restoring a disk that was trashed somehow by a faulty hsz50. I was able to get this restore going last night. This morning I arrive to see the red fault light illuminated on the library, and the message displayed is "DLT timeout, press enter to continue or reboot to clear". I checked my restore job, and it's still going. Very strange, but my experience with libs has been that strange = normal.

Thanks for the help.

[Uwe Zessin]

I won't make friends by writing this ;-) , but tape handling has always been troublesome - welcome to the club!

It is sometimes possible to work around this by giving the tape drive a new SCSI ID and then:

$ run sys$system:sysman
SYSMAN> IO AUTOCONFIGURE

to create a new device entry that can be used until it is convenient to reboot the system and get rid of the inconsistent system state.

[Michael Hogarty]

I hear ya Uwe.

Thanks for the replies all.

[Volker Halle · Accepted solution]

Michael,

the underlying problem in OpenVMS has been finally fixed in patches VMS731_MOUNT96-V0100 and VMS732_MOUNT96-V0100 (released in AUG-2004)

See my reply to the following thread
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=738204

Volker.

[Ian Miller.]

Unfourtunally the patches mentioned do not apply to the unsupported version of VMS that you are currently running (V7.2-1)

[Volker Halle]

Ian,

sure, that's the price you'll have to pay for using older and now unsupported versions of OpenVMS.

I just wanted to provide the information, that this longstanding problem has now been solved. Maybe an incentive for considering an upgrade to a current version ?!

Volker.