topic Re: Help analyzing lock trees in Operating System - OpenVMS

Help analyzing lock trees

Benjamin Levy — Thu, 24 Feb 2011 17:41:25 GMT

Hello

Locking question today

Running Oracle CODASYL DBMS, I have two databases open on the same disk.
I have found the two locks in SDA for these two databases, but I can't
recall how to trace down which lock is for which database?

Thx for any help you can provide!

Ben

$ dbo/sho sys
Oracle CODASYL DBMS V7.2-20 on node ITAWSB 24-FEB-2011 10:22:32.33
- monitor started 19-DEC-2010 02:24:39.22 (uptime 67 07:57:53)
- monitor log filename is "MONITOR1:[DBMMON_ITAWSB]DBMMON.LOG;172"

database DSA299:[COMETS4.DATABASE]COMETS.ROO;1
- opened 19-DEC-2010 02:24:53.42 (elapsed 67 07:57:38)
* database is opened by an operator
- current after-image journal file is
WS_AIJ2:[COMETS4.AIJ]COMETS4.AIJ;1
- 52 active database users on this node
- database is also open on the following node:
- ITAWSA as monitor ID 2

database DSA299:[COMETS8.DATABASE]COMETS.ROO;1
- opened 18-FEB-2011 14:21:53.03 (elapsed 5 20:00:39)
* database is opened by an operator
- current after-image journal file is
WS_AIJ2:[COMETS8.AIJ]COMETS8.AIJ;1
- 20 active database users on this node
- database is also open on the following node:
- ITAWSA as monitor ID 2

$ sh dev dsa299
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA299: Mounted 0 WS_DB2 401869312 1284 2
$1$DGA3299: (ITAWSB) ShadowSetMember 0 (member of DSA299:)

$ ana/sys
SDA> SHOW LOCK 7D065C2D
Lock id: 7D065C2D PID: 0001003F Flags: CONVERT SYNCSTS SYSTEM
Par. id: 00000000 SUBLCKs: 254
LKB: FFFFFFFF.74C45880 BLKAST: 00000000
Priority: 0000
Granted at NL 00000000-FFFFFFFF
RSB: FFFFFFFF.6E8595C0
Resource: 00000044 00000028 (...D... Status: PROTCT VALBLKR VALBLKW
Length 28 20324244 5F535702 .WS_DB2
Exec. mode 00720020 20202020 .r.
System 00000000 0000011E ........

SDA> SHOW LOCK 04001ADD
Lock id: 04001ADD PID: 0001003F Flags: CONVERT SYNCSTS SYSTEM
Par. id: 00000000 SUBLCKs: 257
LKB: FFFFFFFF.738CC180 BLKAST: 00000000
Priority: 0000
Granted at NL 00000000-FFFFFFFF
RSB: FFFFFFFF.6E8AED00
Resource: 00000044 00000028 (...D... Status: PROTCT VALBLKR VALBLKW
Length 28 20324244 5F535702 .WS_DB2
Exec. mode 000D0020 20202020 ...
System 00000000 00000133 3.......

Re: Help analyzing lock trees

Hein van den Heuvel — Thu, 24 Feb 2011 18:04:46 GMT

Why do you care? Just curious?
What problem are you really trying to solve?

Personally I have not touched Locking for the DMBS Codasyl database in decades.

But our friends at Software Concepts International seems to have posted a nice write-up

http://www.sciinc.com/remotedba/techinfo/articles/pi3a5.asp

"DBO/SHOW LOCKS (V4.3 AND BEYOND)
Version 4.3 significantly enhanced the lock summary reports with the addition of the RMU or DBO/SHOW LOCKS command. This new command allows you to show processes that are blocked by another process, processes that are blocking other processes and to select locks held by a specific process. "

Just looking at your output, that "WS_DB2" is probably the device lock name (GETDVI DEVLOCKNAM) for the disk with the root file.
The other components might just be the (HEX) file ID for a root file.
Try $ DIR /FILE DSA299:[COMETS4.DATABASE]COMETS.ROO;1

or use F$FILE ( ..., "FID")
Stick in a DCL symbol SHOW to see the HEX equivalent.

You also want to check SDA> SHOW RESOURCE/LOCK=04001ADD

Hope this helps some,
Hein

Re: Help analyzing lock trees

Benjamin Levy — Thu, 24 Feb 2011 18:34:37 GMT

Thank you

the first field of the FILE-ID matches the hex digits next to "exec mode"

I am trying to write a DCL procedure to direct database backups and similar jobs to the node that holds the lock-master for each database. First step is to determine which node holds the lock-msater for each database.

Re: Help analyzing lock trees

Benjamin Levy — Thu, 24 Feb 2011 18:35:31 GMT

see my last comment for the solution

Re: Help analyzing lock trees

Robert Brooks_1 — Thu, 24 Feb 2011 18:58:55 GMT

Just looking at your output, that "WS_DB2" is probably the device lock name (GETDVI DEVLOCKNAM) for the disk with the root file.

---

If it is the lock name, F$GETDVI/LIB$GETDVI will not return the same string as SYS$GETDVI.

The DCL lexical and RTL (lib$) variant return a hexified encoding of the string, whereas the SYS$ form does return the expected ASCII string.

This is a day-1 bug. There was pretty good disagreement between me and a few folks in VMS Engineering on whether or not it should be fixed. I lost to the possibility that there may be software expects that (weird) output. I think the fact that the three different forms of the service are not consistent is a potentially bigger problem.

-- Rob