From: karsten@tfl.dk (Karsten Nyblad)
Newsgroups: comp.os.vms
Subject: Re: RMS File Lock Questions
Date: 30 Aug 92 20:54:45 GMT
Organization: TFL, A Danish Telecommunication Research Laboratory

In article <14723@mindlink.bc.ca>, Sanyee_Tang@mindlink.bc.ca (Sanyee Tang) writes:
> 
>     I am writing a utility in C to find all RMS locks on a specified file.
> The scheme is:
> 
> (a) Call SYS$PARSE and SYS$SEARCH to find the 6-byte file ID (field NAM$W_FID)
>     and device name (field NAM$T_DVI).  The file could be specified by a
>     logical.
> 
> (b) Call SYS$GETDVI with item code DVI$_DEVLOCKNAM to find the 16-byte device
>     lock name for the device name obtained in (a).
> 
> (c) Call SYS$ENQ to queue a lock on a resource whose name is concatenated as
> 
>         RMS$ + file ID + device lock name
> 
>     and receive a lock-id.
> 
> (d) Call SYS$GETLKI with item code LKI$_LOCKS, passing lock-id returned in
>     (c), in hope to get a list of RMS locks associated with the resource name
>     in (c).
> 
> (e) Print out PID, lock mode and queue for every lock in the list returned
>     in (d).
> 
>     I have coded a test program.  My questions are:
> 
> 1)  Can the above scheme work?  Is the basic idea correct?
 
It depends on what information you want.  RMS does not synchronize opening
and closings of files.  If you what to know who has opened the file, this is not
the way to do it.  The locks on files are the locks prefixed F11B$a.
They are system wide, i.e., one lock per system in the cluster
on which the file is open.  Within each system, access is synchronized
by the XCP it self, and you have to search the WCBs of the file to
find the processes.  I have an incomplete program that does the trick.
Let me know if you want it.  Please indicate if you have a BLISS compiler.

The most interesting RMS locks are the sub locks of the locks
starting with RMS.  It is these locks, that synchronize access to
records, etc.

[RMS does not open or close files.  The XCP does on behalf of RMS.  The
file system on VMS is divide in the XCP, that controls access to files,
and that controls where the files are located on the disk.  The XCP
makes a file look like a consecutive list of blocks to RMS.  The XCP
interfaces to the disk driver and to the user.  RMS uses the normal
user interface to access files.  The XCP knows notthing about the
record layout of files, eventhough it stories the information on
what layout the files have (except for directory files and [000000]*.sys
files).  The RMS knows the record layout of files and synchronize access
to single records in files.  The programming language runtime libraries
are layered on RMS with some exceptions for C.]

> 2)  Apparently I have no access to RMS locks in normal situation.  What
>     happen if I do (c) and (d) in EXEC mode (as same as RMS)?  If I queue
>     a lock in EXEC mode with a valid resource name of a RMS file lock, can
>     I block locks queued by RMS on the same file?  :-)
 
Make sure to take out the lock in NL mode.  Then there is no problems.

> 3)  If I shall change mode and call SYS$CMEXEC (or SYS$CMKRNL), what is the
>     order of the argument list?  In the same order as in C or in a reversed
>     order?
 
The order is always the same:  First the number of arguments, then the
arguments listed in the order indicated in the manuals.

>     I would like to have your experts' opinions before I go further, I am
> a bit anxious about to shut down a busy system unwittingly.  Your help is
> highly appreciated.  I thank Dan Wing, Earl D. Lakia and Martin P.J. Zinser
> for their help for a previous request on lock utility.
> 
> 
> -- Sanyee Tang
>    BC Research
>    Vancouver, Canada