Get currently accessed files

[tobias_beyer]

Hi guys,

you can list the currently accessed files on your device with the DCL command show devices /files.
I need to process this list in a DCL script to check if i can copy a particular file.

My question is, if there is a way to get this information with a lexical function or do i have to pipe the command output?
I searched through the documentation but couldn't find any information, which might fit.

Or does someone knows, where this info is stored? Is there file on each device or is it a file property?

Greetings
Tobi

[volkerhalle]

Tobi,

the information about open files on an OpenVMS volume is only available in the internal system data structures: the Volume Control Block (VCB) for a mounted volume has a list of File Control Blocks (FCB) of open files. That information is only exposed to the user via the SHOW DEVICE/FILES command.

What's the problem you're trying to solve ? Note that even if you check, whether the file is currently open, it might not be, when you try to copy it milliseconds later.

You could also try OPEN/READ/NOSHARE on that specific file - assuming that the file is NOT opened for shared acces by the application, this might be easier than parsing the SHOW DEV/FILES output.

Volker.

[tobias_beyer]

Hi Volker,

thanks for your clarification.

I'm trying to determine, if a software, which is composed of undefined many executables, is correctly shutdown. Those executables all map an overlapping set of global sections into their local space. The copy command to update the global sections still succeeds, even if one of those executables is still running. This is of course the expected result, because the global sections are copied with a new version.
If you restart the software with this unmatching global sections, our internal data gets really messed up and is a pain to fix.

There a of course some other ways, like backup the global sections, delete them and then execute the copy command.
But I like the idea to check, if the copy command can be executed. Instead of resetting the system, if something happened.

Greetings
Tobi

[tim.stegner]

Have each of your executables take out a shared lock, releasing it as part of the image run-down. Then, you can check the lock's existence to determine that all images are shut down. -TJS

[tobias_beyer]

Hi Tim,

thanks for this tip. It's not applicable right now, but I will keep this in mind for hardening the startup and shutdown procedure for the next releases.

Greeting
Tobi