Finding Record Locks

[Robert Atkinson]

I know there are a few utilities to find the owner of record locks, but I've never managed to get any of them working.

Could anyone give me the SDA commands to manually find record locks?

Thanks, Robert.

[Jim_McKinney]

Though I haven't used it, I understand that AMDS is capable of locating the source of blocked locks.

You might also just simply hop into SDA and

SDA> show resources/contention

and see if you 'get lucky'.

Regarding your question... the answer is dependent upon how the record locks originate. Is this a cluster? More importantly, is it RMS that is generating the record locks? Anyone attempting to respond to this would likely want to know.

I don't believe that the format of an RMS lock is documented. (From memory) the resource name consists of the string "RMS$", the 3 words of the file-id, and the associated device lock name.

[Hein van den Heuvel]

I'll attach one of those utilities, but it is also hard to get to work. It needs CMEXEC privs, and you give it a pid, or a device spec as argument. I have some more tools, but those are not mine,

It would help to describe the circumstances better. If one process is waiting for an other holding a lock, then SDA is easy.
Just find the PID of the waiting process. Then:
SDA> SHOW PROCECS /LOCK

Now a record lock will show as an 8 byte long lock name with the VBN and RECORD ID encoded. The parrent of the lock should be a RMS$ file lock as the first reply indicates. The tool helps with this, formatting the lock, and dumping the record.

If a process starts, but dumps out on a locked record, then it is harder to tell, unless you have the target ID or KEY value.
You can use the key with DCL READ/KEY=xxx/WAIT and then use SDA on the DCL process (yourself) as per above.

Or use SHOW DEVICE/FILE and use SDA on each process havign the file open. The tool helps with this situation also.

What is the exact real problem you are trying to solve?

What is the secondary problem you have with the tools. Which tools? Where can we look at them?

You'll find an older version of my tools in:
http://h71000.www7.hp.com/freeware/freeware60/rms_tools

'next' to it you'll find a tool called 'rms_locks' which I have not tried but sounds like it might do the job.

Hope this helps,
Hein.

[Andy Bustamante]

In addition to AMDS, Availability Manager can display "interesting locks" in a system or cluster. See http://h71000.www7.hp.com/openvms/products/availman/docs.html. AMDS and Availability Manager are two sides of the same gem. The data manager display in AM can function on a recent Windows box, which does have a plus or two.


Andy

[Robert Atkinson]

To clarify, we are using RMS indexed files.

We often find programs running in batch 'hang' waiting for a record lock to be released. These locks are taken out by interactive users updating a particular record. As time goes by, a chain of locks can start to accumulate, as more and more users try to access the same record.

Although I do know the file that's being locked and the process PID that's trying to access the record, I don't know which exact record is being locked.

Ultimately, I need to know which user is locking the record the batch process is trying to access, but with 100+ users accessing that particular file, it makes the job difficult.

I had a look at Availability Manager yesterday, but wasn't 100% sure it would give the information I required. I may still install it on our test node and see what it can tell me.

Hein - could you email me an OBJ of your tool - ratkinson-at-tbs-ltd-dot-co-dot-uk.

My assumption is that I'm going to have to cobble together a mixture of tools to do this, which is very annoying, as the code within the application we use is capable of telling you who is locking the record but only sends a message every 10 minutes!

Rob.

[Wim Van den Wyngaert]

Robert,

Users are updating the records while the batch job is running. So, why don't you modify the batch job to read regardless of locks ?

Fwiw

Wim

[Robert Atkinson]

Because the batch process is also updating the records (stock figures).

Due to the way it's designed, there is no other choice but to wait for the lock to be released, from either the interactive processes or the batch jobs.

Rob.

[Volker Halle]

Robert,

AMDS/Availabilty Manager exactly does this job for you. You need to run RMDRIVER (@SYS$STARTUP:AMDS$STARTUP START) on all members of the cluster, which may be involved accessing those ISAM files.

If you run the GUI (data collector), you need to start collecting Lock Contention data. AMDS/Availability Manager will then find blocked locks and also identify blocking locks and show appropriate messages in the Event Windows and also record them in the AvailManLock.Log file.

This only works, if the process is actually waiting for the lock, i.e. the $ENQ operation is pending.

Volker.

[Robert Atkinson]

Thanks Volker.

Are there any 'gotchas' in the AM installation I should know about?

Rob.

[Volker Halle]

Rob,

I would suggest that you read the installation notes...

If your OpenVMS systems have multiple LAN devices, you need to define the correct device in AMDS$LOGICALS.COM. The AMDS LAN protocol only works on the same LAN segment, so you need to connect your AM data collector (GUI) to the same LAN segment as your OpenVMS nodes. You may also install and run the GUI on a Windows system.

Here are some examples of lock related AM messages (from the Availability Manager event log - V2.6A):

LCKCNT AXTST1 possible contention for resource QMAN$JBC_ALIVE_01

LCKBLK AXTST1 JOB_CONTROL blocking resource QMAN$JBC_ALIVE_01

LCKWAT AXTST1 QUEUE_MANAGER waiting for resource QMAN$JBC_ALIVE_01 granted to QUEUE_MANAGERQUEUE_MANAGER on node AXTST1

Note that the contents of the LCKWAT message is incorrect regarding the blocking process name - this has already been reported.

The Lock Contention information in the AvailManLock.Log file is more detailled and correct.

Note that you can also follow the blocked locks using SDA, but this is very tedious and time-consuming, especially in a cluster.

Volker.