URGENT !!! Tape owner proccess nonexistant

[Chaim Budnick]

A backup was aborted and now the tape drive has an owner process id of a nonexistant process.

How do I get out of this??

Thanks,

Chaim

[Chaim Budnick]

Forgot to mention:

VMS V7.2-1

MOUNT/ABORT did NOT work

[Ian McKerracher]

Chaim,

Try the following command:

$ dismount/abort

If the tape-owning process was running in batch mode you may need to delete the batch queue entry i.e.

$ del/entry=

Hope this helps,

Ian

[Chaim Budnick]

I had already tried dismount/abort , but this tells that the device is NOT mounted.

mouunt tells me that the device is owned by another process (which is nonexistant)

Chaim

[Uwe Zessin]

The service/ support organization can provide you with a program that clears the owner id. It is a bit riscy, because the integrity of the system is no longer assured. If possible, try to reboot the system to get a clean system state.

[Chaim Budnick]

OK!

That is what I suspected.

Thanks,

Chaim

[Volker Halle]

Looks like this (or at least one other reason leading this this kind of problem) has now finally been addressed in VMS731_MOUNT96-V0100 and VMS732_MOUNT96-V0100.

Volker.

[Ian Miller.]

When unable to reboot the system I have worked around this by changing the tape drive scsi id to another value (generally the tape drive is on a scsi bus alone) then using MCR SYSMAN IO AUTOCONFIG to pick the new device name and changing the DCL procedures to use the new tape.

I hope that this classic feature is finally nailed with the patches Volker mentioned.

Unfourtually they don't apply to the unsupported version of VMS you mentioned

[Uwe Zessin]

Tape handling has _always_ been a problem for VMS. This problem is an old one and seems to pop up every few years.

[John Gillings]

re: Uwe: "Tape handling has _always_ been a problem for VMS. This problem is an old one and seems to pop up every few years."

Tape handling itself isn't the problem. It's when people attempt to kill processes that own tape drives.

The crux of the problem is that tape operations can take a long time, if you attempt to kill a process while it's waiting for an operation to complete, you can leave the system in an inconsistent state. The tradeoff is in trying to protect the system, but still let you abort tape operations. Unfortunately there are many timing windows that can be quite wide. Over the years we've closed many of them and narrowed others, but I don't think the issue will ever be completely resolved.

Best way to avoid this kind of trouble is to NOT use STOP/ID. Always attempt to work out what's wrong before killing any job. Once you've issued STOP/ID you can't back out, and you usually destroy any available evidence to analyze the problem.

From V7.3 if you MUST kill a process, try STOP/IMAGE/ID first. This will issue a $FORCEX rather than $DELPRC and has a much better chance of leaving the system in a clean state.

[Thomas Schick · Accepted solution]

What is the device status of your tape drive (MKxnnn:)?
In case of "MountVerification" the IPC program could help you.

$ reply/enable
Ctrl^P ! on OPA0:, press the keys [CTRL] and [P]

>>> D SIRR C
>>> cont
IPC> C MKxnnn:
IPC> Ctrl^Z
$

Thomas