- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Find out who has a particular file open in i/o...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 03:50 PM
тАО07-13-2010 03:50 PM
Re: Find out who has a particular file open in i/o mode
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/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 04:24 PM
тАО07-13-2010 04:24 PM
Re: Find out who has a particular file open in i/o mode
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 :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 04:39 PM
тАО07-13-2010 04:39 PM
Re: Find out who has a particular file open in i/o mode
--
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 12:27 AM
тАО07-14-2010 12:27 AM
Re: Find out who has a particular file open in i/o mode
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 12:50 AM
тАО07-14-2010 12:50 AM
Re: Find out who has a particular file open in i/o mode
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 03:29 AM
тАО07-14-2010 03:29 AM
Re: Find out who has a particular file open in i/o mode
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 05:21 AM
тАО07-14-2010 05:21 AM
Re: Find out who has a particular file open in i/o mode
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 :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 07:03 AM
тАО07-14-2010 07:03 AM
Re: Find out who has a particular file open in i/o mode
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 02:59 PM
тАО07-14-2010 02:59 PM
Re: Find out who has a particular file open in i/o mode
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 06:51 PM
тАО07-14-2010 06:51 PM
Re: Find out who has a particular file open in i/o mode
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.