The Question is:
Here is a strange one. Happens to us randomly anywhere from once every few
days to every few months...
Let me include a few lines from a log file to show you what is happening:
$ RENAME/LOG DCP:PALLT_BC_LABEL.20030325010430 DCP:LOFT_DATA_LABEL.PAS;1
%RENAME-I-RENAMED, EMS_DATA:[CP]PALLT_BC_LABEL.20030325010430;2 renamed to
$ SET NOON
$ GOTO COPY
$ COPY/LOG DCP:LOFT_DATA_LABEL.PAS;1 DCP:LOFT_DATA_LABEL.TMP;
%COPY-E-OPENIN, error opening EMS_DATA:[CP]LOFT_DATA_LABEL.PAS;1 as input
-RMS-E-FLK, file currently locked by another user
Ok - that is what we are seeing. What we absolutely know is that NO other user
could POSSIBLY have that file locked. Therefore, only conclusion we can come
to is that somehow VMS still has not released the lock on that file. Is it
possible that the REN
AME command operates asynchronously and sometimes has not released the lock on
the file when a copy is done immediately after the rename? Or is there
something more sinister at work here???
Thanks for your input.
The Answer is :
RENAME is synchronous.
The OpenVMS Wizard would assume that something or someone has that
file locked, and is presently unwilling to assume that there are no
(other) users and no (other) processes that might have it locked.
Either on this node, or elsewhere within a cluster.
The OpenVMS Wizard will assume you have the current ECO kits for
OpenVMS loaded. If not, start there. Once you have current ECO
kits, please contact the support center for further assistance.