o To use the RMU Show Locks command for a database, you must
have the OpenVMS WORLD privilege.
o When you specify a list of processes or lock identifiers, make
sure the processes or locks are local to the node on which the
RMU Show Locks command is issued.
o To display the complete list of locks in the OpenVMS locks
database, do not specify the Mode=Blocking or Waiting
qualifier. The volume of information from this report can
be quite large.
o If you have entered an Oracle RMU command and there are no
locks on your node, you receive the following message:
%RMU-I-NOLOCKSOUT, No locks on this node with the specified
qualifiers.
o When you use the RMU Show Locks command to display locks,
the "requested" and "granted" modes of the given lock are
displayed. The definitions for the two fields follow:
- Requested
This is the mode for which the process has requested
the lock. Valid modes are NL, CR, CW, PR, PW, and EX.
This mode is not guaranteed to be granted; some locks
are intentionally held in conflicting modes forever (for
example, the "termination" lock).
- Granted
This is the mode that the process was last granted for
the lock. Valid modes are NL, CR, CW, PR, PW, and EX.
Furthermore, if the lock has never been previously granted,
the lock mode is displayed as NL mode.
Lock Mode Compatibility shows the compatibility of requested
and granted lock modes.
Table 18 Lock Mode Compatibility
Mode of Currently Granted Locks
Mode of
Requested
Lock NL CR CW PR PW EX
NL Yes Yes Yes Yes Yes Yes
CR Yes Yes Yes Yes Yes No
CW Yes Yes Yes No No No
PR Yes Yes No Yes No No
PW Yes Yes No No No No
EX Yes No No No No No
__________________________________________________________________
Key to Lock Modes
NL-Null Lock
CR-Concurrent Read
CW-Concurrent Write
PR-Protected Read
PW-Protected Write
EX-Exclusive Lock
Yes-Locks compatible
No-Locks not compatible
o If the "requested" and "granted" lock modes differ, then the
lock requested is currently blocked on either the "wait" or
"conversion" queue. If the modes are the same, then the lock
has been granted.
o The OpenVMS distributed lock manager does not always
update the requested lock mode. This means that potentially
conflicting information can be displayed by the RMU Show Locks
utility.
o The requested lock mode is updated only under the following
situations:
- The lock request is for a remote resource.
- The lock request is a Nowait request.
- The lock request could not be granted due to a lock
conflict (that is, it was canceled by the application or
aborted due to lock timeout or deadlock).
- The lock request is the first for the resource.
o Consider the following RMU Show Locks output:
---------------------------------------------------------------------
Resource Name: page 533
Granted Lock Count: 1, Parent Lock ID: 01000B6C, Lock Access Mode:
Executive,
Resource Type:
Global, Lock Value Block: 03000000 00000000 00000000 00000002
-Master Node Info- --Lock Mode Information-- -Remote Node Info-
ProcessID Lock ID SystemID Requested Granted Queue Lock ID SystemID
2040021E 0400136A 00010002 EX CR GRANT 0400136A 00010002
------------------------------------------------------------------------
In this example, it is ordinarily difficult to explain how
such a combination of lock modes could occur. Note that the
CR (concurrent read) mode is on the Grant queue (not the
Conversion queue).
Knowledge of the operating environment is necessary to know
that there was only one node on this system. It turns out that
two lock requests actually occurred to generate this output,
in the opposite order of what appears to have occurred.
The first lock request was for EX (exclusive), which was
immediately granted. Thus, the Requested and Granted modes
were updated according to situation 4. Then, the lock was
demoted from EX to CR mode, which was also immediately
granted. However, the Requested field was not updated because
none of the four preceding rules was true, so the Requested
mode was never updated to reflect the CR lock request.
o