Operating System - OpenVMS
1748088 Members
4908 Online
108758 Solutions
New Discussion юеВ

Re: Find out who has a particular file open in i/o mode

 
Phil.Howell
Honored Contributor

Re: Find out who has a particular file open in i/o mode

From decus/freeware there are some other options.
One that I used ages ago, but may only work on vax is findlock from Mr. Lomasky http://www.digiater.nl/openvms/decus/vax90a/lomasky/

Also on more recent freeware - DBS-SCANLOCKS
http://www.digiater.nl/openvms/freeware/v80/dbs-scanlocks/

and findlocks
http://www.digiater.nl/openvms/freeware/v50/findlocks/
Richard J Maher
Trusted Contributor

Re: Find out who has a particular file open in i/o mode

Hi Homer,

As usual, with anything RMS (most things really) I'd go with Hein's advice.

Having said that there would be easier code (and in better languages) just to emulate the RMS file lock (DVI$_DEVLOCKNAM + FID in EXEC mode IIRC) and then do a $GETLKI to see who's blocking you.

If no one else has a simple example from one of the freeware tapes and/or you'd like and example in the language you're already using then let me know.

Cheers Richard.

PS. I thought there were some good (similar to RDB's rmu/show locks/mode=blocking or culprit etc in freeware somewhere?)

PPS. Bad luck to the Oranje :-)
Robert Brooks_1
Honored Contributor

Re: Find out who has a particular file open in i/o mode

Having said that there would be easier code (and in better languages) just to emulate the RMS file lock (DVI$_DEVLOCKNAM + FID in EXEC mode IIRC) and then do a $GETLKI to see who's blocking you.

--

Yeah, good luck! dvi$_devlocknam returns a string that's perhaps not what one would expect!

From EISNER::

$ write sys$output f$getdvi( "$1$dga1:", "devlocknam" )
000000202020205359534148504C4102

I tried to fix it, but was rebuffed under the "we don't want to change existing behaviour" reason.

If you "dehexify" the string, you should be able to feed it to $getlki . . .

-- Rob
Richard J Maher
Trusted Contributor

Re: Find out who has a particular file open in i/o mode

Rob,

I think you'll find that it's only a nicety of the F$GETDVI lexical to convert it to a hexidecimal string on output and that sys$getdvi returns a lovely 16 byte dvi$_locknam as usual. And the volume lock living in bytes from 2 for 12.

But then I'm sure someone that works with VMS i/o would know that, so I'm going to write a little tester toi make sure.

I've been in bed sick most of the day and I've just found an old program that suggests in the strongest possible terms that the RMS resource name for file is "RMS$" + FID + DEVLOCKNAM at exec mode.

I'll give it a go and report back.

Cheers Richard Maher
Richard J Maher
Trusted Contributor

Re: Find out who has a particular file open in i/o mode

No need, just looked at Hein's code and that is in fact the case.
abrsvc
Respected Contributor

Re: Find out who has a particular file open in i/o mode

While the utilities already discussed may get you moveing in the short term, perhaps a different avenue should be followed for the long term.

A similar issue arose with software that i currently support as well. The solution here was to create and use a lock on the file as a resource. Each process that takes out the lock can be seen in SDA by using the SHOW LOCK/NAME="x" command. If you take out the lock in CW mode when updating the file, the list should be easily seen. This would require a call to the ENQ system service along with the open statement. Also, if your program needs exclusive access, the lock mode would be EX for you and that can trigger an AST for the other programs to take action. That action might be to close the file until awakened by another AST sent by you.

Yes it will take program modifications, but if implemented properly, will renmove any manual intervention in the future.

Dan
Richard J Maher
Trusted Contributor

Re: Find out who has a particular file open in i/o mode

Hi Hein,

If I follow you correctly you're saying that the RMS$+FID+DEVLOCKNAM is simply a RMS place holder parent resource for child record locks and does not serve a meaningful purpose with regard to file-locking?

If I've misunderstood please let me know.

If the XQP is where all the magic lies can you please detail the DLM reasource names reqd to successfully maintain a file lock?

Ok, so as bad luck would have it, it's all at kernel mode and I guess we're still talking FIDs and DEVLOCKNAM(VOLNAMs)

From my lovely DIR_WATCH utility (for checking when a file is created) I am comfortable with the "F11B$v" + volname as the parent followed by "F11B$s" + DID for the child as the serialization lock but, if I want to place a lock on a particular file, what is the "x" in "F11B$x", is it a child of the volume lock, and am I correct in presuming the rest of the resource name is just the FID?

Cheers Richard Maher

PS. Still coughing up oysters so might have time to do it tomorrow :-)
Hoff
Honored Contributor

Re: Find out who has a particular file open in i/o mode

Others have better addressed the immediate question.

Here's an overview of locking and a quick review of the groups of locks used by RMS, and some example code:

http://labs.hoffmanlabs.com/node/492

http://www.eight-cubed.com/examples/framework.php?file=sys_cmexec.c

AFAIK, the format of and details of the RMS locks are not officially documented. As for available documentation resources, have a look at Kirby McCoy's VMS File Systems book, and look in the appendices of most any "recent" VMS Internals and Data Structures (IDSM) book.

ANALYZE /SYSTEM (SDA) in recent releases has good lock tracing, and (depending on what you're up to) the AMDS and AvailMan tools can be used to locate processes holding blocking locks. (SDA, AMDS and AvailMan are obviously not APIs, so there's no good way to use these tools from a program. But they're very handy for poking around.)

In the longer-term, have a look at centralizing the core file I/O calls into (for instance) shareable image(s), of logging and tracing; of potential application enhancements. Features such as quiescing or cleanly exiting the open files when required; of coordinating and providing consistent backups of the data. Whatever you want to call the task; retrenchment, improvements, optimization, reducing support costs, integrated debugging, streamlining...
Robert Brooks_1
Honored Contributor

Re: Find out who has a particular file open in i/o mode

Richard wrote . . .

I think you'll find that it's only a nicety of the F$GETDVI lexical to convert it to a hexidecimal string on output and that sys$getdvi returns a lovely 16 byte dvi$_locknam as usual. And the volume lock living in bytes from 2 for 12.

RAB: Yes, you are correct; the SYS$ variant does work as expected. However, the LIB$ variant (in addition to the DCL lexical) also behaves in an undocumented (and wrong) fashion.

Richard also wrote . . .
But then I'm sure someone that works with VMS i/o would know that, so I'm going to write a little tester to make sure.

RAB: Touche!

-- Rob
Richard J Maher
Trusted Contributor

Re: Find out who has a particular file open in i/o mode

Ok this is beginning to sound too difficult.

See below for a snippet that looks to come from a "Perfect Disk" patent application I found on the web.

So I'd be more than happy with the serialization locks F11B$s and the arbitration locks F11B$a but judging by my SDA (on a system that is not in a cluster) you don't get arbitration locks at all when you open a file. Have I stuffed up somewhere or, on single node boxes, are we forced to walk some FCB chain?

Someone got the Internals book handy?

(Is there a bit of deja-vu creeping in here? This is one of those posts that comes round every few years isn't it?)

Cheers Richard Maher

<<<<<<<<<<<<<<<<<<<<<<

When PD determines that it would like to move a particular file, it starts by taking out a ├в file serialization├в lock in ├в protected read├в (PR) mode with a ├в blocking AST├в (the blocking AST causes a notification if another user tries to take out an incompatible lock). While it holds the F11B$s lock in PR mode, no other users in the cluster can change the state of its access. In particular, if no other user has the file open, then no other user can access the file while the lock is held.

After PD acquires the lock, it checks locally to determine if another user has the file open locally. This is done by searching the file control blocks (FCBs) maintained in main memory by the XQP for all open files. If it is not open on the local node, then PD takes out a ├в file access arbitration├в lock (referred herein as the F11B$a lock) in null (NL) mode. If a file is open on any node in a VAXcluster, then there exists such a lock on that node. PD can then do a $GETLKI (get lock information) system call and determine how many such locks exist in the cluster. If there is more than one (PD's lock), then another user has the file open and PD will not attempt to move the file. PD then drops the F11B$a lock since it has no further use for it at that time. Assuming the process is to continue, PD then allocates space on the disk at the target location for the defragmented/optimized version of the file. It reads the file data from the old location and writes it to the new location. A verification pass can be performed if desired to guarantee that the data was correctly copied. Up to this point, if the system crashes for some reason, the old file exists as always and there is no problem. The space allocated for the new version of the file will be deallocated when the disk bitmap is rebuilt, a normal operation at start-up.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

PS. Nice overview Hoff but a bit more detail on the resource-name and hierarchy convention for file-locks would be much appreciated.