topic Re: File locked in Operating System - OpenVMS

File locked

nipun_2 — Mon, 13 Aug 2007 16:09:32 GMT

Hello all,
I am running OpenVMS 7.3-2 and I recently wrote a script.

Users have submitted this as a queue using the submit command which is normally done with other scripts often used in our lab.

However, the first couple of entries ran fine. However, later on an error was reported stating

"File (the script file) locked by another user"??

%DCL-E-OPENIN, error opening DISK1:[XXXXX.XXXX]TEMP_XXX.COM; as input
-RMS-E-FLK, file currently locked by another user

Why does this kind of error occur and how can we correct for this problem ?
Could this be because the file has been left open ? by a user or are their file security issues.

Some details would be very helpful if this is indeed a simple answer.

In case more information is required can you please let me know what that would be and what commands should I use to get the same.

thanks in advance.

Re: File locked

Thomas Ritter — Mon, 13 Aug 2007 16:48:37 GMT

Step 1, find out what is locking the file.
Try $ show dev/files disk1 and look for the file name.

Better
$ pipe show dev/files disk1 | sea sys$input temp_xxx.com

Re: File locked

Steven Schweda — Mon, 13 Aug 2007 17:24:02 GMT

First, it would be most helpful if you showed
actual commands and actual output instead of
vague descriptions and edited output.
Unless, of course, you really have a
directory named "[XXXXX.XXXX]", and a
procedure named "TEMP_XXX.COM".

> "File (the script file) locked by another
> user"??

You mean that _your_ procedure is named
"TEMP_XXX.COM"? From that name, I'd have
guessed that your procedure (whatever it's
called) creates a _temporary_ file named
"TEMP_XXX.COM", and when you run it twice at
the same time, both jobs use the same
temporary file name, and _that's_ what's
causing the file access conflict. If that
were the case, I'd suggest incorporating the
process ID (f$getjpi( "", "PID")) in the
temporary file name to avoid that sort of
collision.

However, we can't see your procedure, and we
can't see what it really did, so it's not
easy to say (with any confidence) what went
wrong.

Re: File locked

Hoff — Mon, 13 Aug 2007 17:44:29 GMT

Two users -- or the same user twice -- has the file held open.

If you're working with a scratch area, you either need to use unique filenames, or you need to use unique scratch areas.

I tend to redefine SYS$SCRATCH, and toss the temporary files over there.

Here's some troubleshooting info:

http://64.223.189.234/node/217

There's a case where you can get into trouble with an exit path -- where the file isn't closed -- and this can manifest itself in several ways. To avoid this at run-time...

If you're using a DCL command such as the following:

OPEN/WRITE foo filename

Issue the following command just before the OPEN:

CLOSE/NOLOG foo

http://64.223.189.234/node/383

And within the application procedure itself, ensure the procedure closes the file on the way out.

If you're intending to share the file, use the /SHARE qualifier on the open.

There's a write-up on sharing file access from within C -- the C extensions related to file locking and file sharing -- available within the OpenVMS FAQ.

http://www.hoffmanlabs.com/vmsfaq/

The details are easier to find within the text or PDF versions. HTML is hard to search.

And the DCL command SHOW DEVICE ddcu:/FILE will show you which process has the file opened on the particular device, as was mentioned previously in this thread.

Stephen Hoffman
HoffmanLabs LLC

Re: File locked

Willem Grooters — Wed, 15 Aug 2007 10:02:57 GMT

$ SHO DEV/FILES could tell you more. also, think about installed images that could have a channel opened. Thinking that way, SDA might give you a clue as well.

Re: File locked

nipun_2 — Thu, 16 Aug 2007 10:32:11 GMT

Thank you all for your help.

The file was locked because it was being used by multiple users. Thanks for your feedback Hoff.

I corrected that by using F$search lexical to search and create a specific com file for every execution and deleting the specific version of the file in the end to resolve any ambiguities.

This took care of things in a nice and neat manner.