to delete a file locked by user

[nipun_2]

Hi,
I am running openvms V 7.3-2 on a 3 node cluster system. I am trying to delete a file however when I give the command

del FILENAME.EXT;1
it give the message
file currently locked by a user and it does not allow me to delete it. I have tried loggin in from sys admin and deleting.

I also did

set prot o:rwed FILENAME.EXT
set file /owner=USER (but it gave here file locked)

I was able to rename the file but not delete it.

Please let me know how to go about this problem.Thanks in advance.

Nipun

[Ian Miller.]

A process still has that file open. Try
$ MCR SYSMAN SET ENV/CLUSTER
SYSMAN> DO PIPE SHOW DEVICE/FILES devicename | SEARCH SYS$INPUT filename

to see which process still has the file open.

You can rename the file because that changes the directory entry not the file.

[Kris Clippeleyr]

Nipun,

"currently locked by another user" simply means that the file is held open by another process in a mode incompatible with the attempted access (in this case DELETE).
You'll have to wait until that process releases the file, and then try to delete it.
Regards,
Kris (aka Qkcl)

[Hein van den Heuvel]

The term 'locked by other user' really means it. It might be more clear to write that as 'opened by an other stream'. That stream might be idle but it has aquired the right to use the file so it would be wrong to yank away the file. That other user can be the same username, it can even be the same process. For example:

$ open/write x tmp.tmp
$ dele tmp.tmp.
%DELETE-W-FILNOTDEL, error deleting U$1:[HEIN]TMP.TMP;1
-RMS-E-FLK, file currently locked by another user

As replied earlier, you can use SHOW DEV/FILE to find out which process has the file open. You then may have to kill that process to delete the file. In the case of the example above a simple 'close x' will do the trick.

If you want to delete a write accessed file (using RMS) which allows other writers, then you will have to open it with SHR=UPD, then set FOP=DLT and close. Thise will "mark the file for delete". The actual delete will happen when the last accessor closes the file. You may also want to check out the ACP QIO interface for more tricky stuff.

If the write does not allow sharing then you'll have to shoot the writer (process).


hth,
Hein.

[Mike Reznak]

Hi,

You may also find out, that the file is locked by process which is not possible, for some reason, kill by STOP command. Then the reboot is the option.

Mike

[Hein van den Heuvel · Accepted solution]

Nah, rebooting a VMS cluster (member) is never a reasonable option.

Just not deleting the file would seem far easier. Just rename it and walk away, hoping nobody saw you :-).

If it contains data that needs to be erased, then open it with a program using and ACP QIO with FIB$V_NOLOCK set in FIB$L_ACCTL.

Hein.

[Willem Grooters]

I remmember I've seen this question before and likely somewhere else, quite recently, but I cannot remember where....
With the chance of repeating myself:

FIRST of all determine WHO is holding the file. Since this is a cluster, it can be one, or more proces(ses) on any node.
So what you need to do first is

$ PIPE SHOW DEVICE/FILES | SEARCH SYS$PIPE

If the file resides on a directory that includes a logical (or is one itsel), you may use that logical. VMS is intelligent enough to translate ;-)

If you find a line with the user, notify that user that he is required to stop the program or function he's working in.
If it a batchjob, you have to stop it.
If it is a detached process, you need to stop it.
If you find a line of this file but no user mentioned, the file might be installed. You first have to deinstall the file before you can delete it.

Another source is $ ANALYZE/SYSTEM and find out who's accessing the file but you will have to check each process (I think).

Reboot would only be feasable if the file is not in use by anyone, not installed or otherwise in use - NOWHERE in the cluster. Worst case, you would need to reboot each machine.
Nevertheless: I would not recommend it, and certainly not for this type of issue. If you are really need it deleted, I would strongly syggest to make a crasdump before reboot. That is: of aall the nodes. Afterwards, I'd log a caal at HP to examine the issue, and they would like to have the dumps.
Therefore, I would want to be absolutely sure that it really is a VMS issue, and not a user's error. Just because of the cost involbed.

[nipun_2]

thanks for your responses. I renamed the file and somehow next day I was able to delet the renamed file.

Nipun