File locked

[nipun_2]

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.

[Thomas Ritter]

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

[Steven Schweda]

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.

[Hoff · Accepted solution]

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

[Willem Grooters]

$ 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.

[nipun_2]

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.