|
HP OpenVMS Systemsask the wizard |
|
The Question is: We upgraded from 7.2 to 7.3. Our software has about 30 locks that we use using the distributed lock manager. This software isn't running on a cluster. When the software starts up it performs an sys$enq to grant all the locks in CR mode. From then unti l the user exits the program we do lock conversions using just CR (Concurrent Read), PR (Protected Read) and PW (Protected Write). These locks are never in PR or PW for more than a fraction of a second. However they may stay in CR for long periods of ti me. Starting in 7.3 we frequently get the VMS error "Conversion of an ungranted lock". Since this is running on approx 100 CPUs around the country on Police/Fire 911 systems, we are telling everyone not to upgrade to 7.3. The one site that did upgrade, the situation became unbearable, so we re-installed 7.2 and life is good again. Is there any new timers that only allow you to hold a lock for a certain amount of time? We keep all of our locks granted all of the time, they remain in CR mode when idle. We did some workarounds for this situation (i.e. if the software detects this error, then regrant the lock and continue), then we started getting lot's of deadlocks, which also shouldn't have occurred. This software have been around for almost 20 years (lot's of changes), but the locking mechanism hasn't changed much since vms 3.x. We will need a resolution before we can upgrade to 7.3 and beyond. The Answer is :
Probably the most common source of this error is a failure to correctly
synchronize lock operation completions -- you cannot convert the lock
until it has been granted. The OpenVMS Wizard is aware of cases of
this error when $ENQ is called -- rather than $ENQW, for instance --
and its completion is not properly checked (eg: via a cal to $SYNCH)
prior to the attempted lock conversion. (At least one such case of
this programming error was identified within an OpenVMS component.)
Please see Ask The Wizard topic (1661) for a list of some of the more
common programming errors.
Errors due to unsynchronized completions are obviously dependent on
timing, and there have been various performance enhancements made in
the lock manager in recent OpenVMS releases -- the lock manager is
rather faster with V7.2 and V7.3, and additional lock manager
performance improvements are underway.
There are no timers and no time-out on lock ownership. That said,
if you are using your own deadlock processing -- for instance, if
you have a door-bell scheme and/or have a blocking AST routine that
will (eventually) release the lock -- you will want to specify the
LCK$M_NODLKBLK option on the $ENQ[W] call.
As for the error itself:
CVTUNGRANT, cannot convert an ungranted lock
Facility: SYSTEM, System Services
Explanation: An attempt was made to convert a lock that is not granted.
(Only locks that are granted may be converted to another lock
mode.)
User Action: See the section on the lock management services in the OpenVMS
System Services Reference Manual and correct your program.
|