The Question is:
A batch job is attempting to replace an image derived from a Fortran program
with an updated version of the program. When using DELETE from within INSTALL
to remove the origial file an error message - "... file locked by another
user" is produced. When
using UNLOCK a message is returned indicating that the file is not locked.
Subsequent attempts to re-run the job return the same error. This job has
worked fine in the past. Using the VMS DELETE command on the file produces the
The Answer is :
The DCL UNLOCK verb is rather confusing, and is only relevent to the
ACP-QIO deaccess locking support. This support is typically only
used with older applications, or applications that wish to maintain
their own consistency without the use of the OpenVMS lock manager
and RMS. Files that are locked using RMS and the OpenVMS distributed
lock manager are not affected by nor particularly relevent to the DCL
UNLOCK and SET FILE/UNLOCK verbs.
Put another way, if the particular error message reported is FILELOCKED,
then the UNLOCK and SET FILE/UNLOCK are relevent and useful. If the
error message is FLK (as it appears to be -- please don't abbreviate
error messages), then the DCL commands UNLOCK and SET FILE/UNLOCK are
not relevent and are not useful.
nb: SET FILE/UNLOCK is not currently available on OpenVMS Alpha.
Assuming this is the FLK error, then the available AMDS and SDA tools
can be used to track down the lock holder. Short of a system reboot,
the identification of the current lock holder is a necessary step in
the process of releasing the particular file lock involved here.
The OpenVMS Wizard would also recommend the use of the current INSTALL
command syntax, and not the (very old) foreign-command syntax used for