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

[Homer Shoemaker]

OpenVMS V8.3 on node P2660 13-JUL-2010 09:27:25.53 Uptime 404 12:21:32
System: P2660, HP rx2660 (1.59GHz/9.0MB)
HP Cobol compiler version 2.9

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

When we run the program that checks for locked files prior to running an AP post using the code below we get our message telling us the file is in use. And that's fine.

MOVE "VENDOR" TO FILE-NAME.
OPEN I-O VENDOR ALLOWING READERS.
IF NOT SUCCESSFUL
PERFORM 900-DISPLAY-MESS-BEEP
MOVE 6 TO JCL-CODE
GO TO 999-TIE-UP.
CLOSE VENDOR.

There are many people running programs that could have opened the file.

What I have tried:
(1)
$ INQUIRE/NOPUNCTUATION FIL
$ FILNAM = F$SEARCH("''FIL':")
$ DRV = F$PARSE("''FILNAM'",,,"DEVICE")
$ SHOW DEV/FILES/NOSYS/OUT=FS1.TMP 'DRV'
$ SEA FS1.TMP 'FIL'

I may see thirty users, many with multiple sessions, with processess using that file. I cannot call every one of them and ask them to please back out of the program that they're using just to see if they're the one who has the file opened in i/o mode. It takes too long and I'm interupting too many people.

(2)
$ MYPID = F$GETJPI("","PID")
$ MYUIC = F$GETJPI("","UIC")
$ MYGRP = F$GETJPI("","GRP")
$ NEXT_ID = ""
$!
$GETID:
$ PID = F$PID(NEXT_ID)
$ IF PID .EQS. "" THEN GOTO FINISH
$!
$ UIC = F$GETJPI(PID,"UIC")
$ GRP = F$GETJPI(PID,"GRP")
$ INM = F$GETJPI(PID,"IMAGNAME")
$ SNM = F$PARSE(INM,,,"NAME")
$!
$ WRITE SYS$OUTPUT UIC," ",SNM
$ GOTO GETID

I can also get a list of all the images in use by all the process on the system. And then search the list for images that I know can open the file in i/o mode. The problem is that many of them can, depending on parameters passed to them at program startup, or switches in another file defining user permissions, or which features of the program are being used. Consequently, this doesn't narrow my search much at all. There are many people executing images that could have opened the file.

(3)
I looked into using files_info from the freeware disk. But I got in over my head quickly trying to get it to work on Integrity. I don't think the macro's are going to work.


Anybody have any ideas?

[P Muralidhar Kini]

Hi Homer,

>> Find out who has a particular file open in i/o mode.
By I/O mode, do you mean to find out if
- any process doing a write IO to the file currently (Read IO is ok) ??
or
- any process is doing a Read/Write operation to the file currently

Regards,
Murali

[Homer Shoemaker]

I mean, who has opened the file so that I cannot open it ALLOWING READERS only.

[Homer Shoemaker]

We use the COBOL OPEN statement, and the files that I am talking about are existing and indexed, so that we usually only open them using OPEN INPUT or OPEN I-O. So when I referred to i/o, I was referring to the COBOL syntax. Sorry for the confusion.

Can you help with the problem?

[Hein van den Heuvel]

>> Anybody have any ideas?

I have an idea, but not a finished solution, and no time just now to finish it.

You can perhaps use the attached source for a program which display RMS record lock holders.

This is a relatively new, not yet published tool precisely because I wanted to add file lock handling. It is in production for record locks.

The first step of the idea is to simply construct an RMS$ file lock resource name, get a (NL) lock and use GETLKI to query that lock for details on other holders.

The second step is to convert the lock, asynchronously to a blocking situation (because of those IO users) and NOT to wait, but to use GETLKI with the LKI$_BLOCKEDBY option to directly get a list of blockers.

That's what the program does for record locks already, but not yet for file locks.
Look for the comment 'qqq' or text: 'implemented'. SMOP!

Oh, and you'll need CMEXEC for the RMS lock, and CMKRNL is we need the XQL lock for the file of course.

Hope this helps some,
Hein

[Steven Schweda]

Perhaps:

help show devices /files

[Homer Shoemaker]

Hein:

SMOP! Indeed! LOL. I am going to get an education just following what you have already done. Let alone adding to it. Thank you very much. If I succeed I will post it here.

Steven:

Thank you for your response. I did try that. See (1) above for the problems that I ran into. I do value the generous contributions of time and effort from the experts and colleagues that I find here. Is there something else I missed?

[Verne Britton]

Brute force ??

Assuming you have all the source code, search everything to find the programs that do not play nice with others :-)


Verne

[Homer Shoemaker]

Verne:

Thank you for your reply. Well, that's certainly a possibility. But I think quite involved. And though it may come to that, I'm going to hold off for now.

It's not that the other programs don't play nice, it's just that they necessarily restrict the way the file can be opened by a subsequent program. I cannot just prevent end users from doing their jobs. (Then I wouldn't have a job!) And since the same program can open a file different ways depending on what the user wants to do, I would have to create a way to track which users have opened the file in a certain manner. Maintaining that list could be troublesome. But I think the OS is already doing that anyway, and probably better than I could.

[John Gillings]

Homer,

I'm not sure I understand this:

"checks for locked files prior to running an AP post"

What's the reason for checking, and what do you want to do with the process(es) when they're found?

Maybe instead of building complex privileged programs which dig into OpenVMS data structures to find PIDs, then deal with all the nasty timing issues you WILL encounter at the worst possible time (consider what if someone starts another program after you've scanned, but before whatever it is you want to do with exclusive access?), perhaps consider designing a mechanism by which your programs can cooperate in how they access the file.

Thinking on the fly, maybe something using (non-privileged) locks and blocking ASTs to signal processes that they should relinquish write access to the file?

Another option might be to have processes that open key files for write access put a flag in a shareable logical name table (LNM$JOB?) noting their PID. Program the equivalent of

$ DEFINE/JOB RW_ 'F$GETJPI("","PID")

You could then find the processes with:

$ SHOW LOGICAL/TABLE=* RW_