From: Keith Parris [keithparris_NOSPAM@yahoo.com] Sent: Thursday, June 12, 2003 1:41 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: BLASTed directory locks, timing windows & endless loops "Richard Maher" wrote in message news:... > I just don't seem to be able to find these locks with SDA. What am I doing > wrong? It appears I gave you a bum steer on the RMS$ lock idea. Sorry. See below. > Could you please go to one session and do a $create x.x and then go to > another session and do a SDA> show locks/brief/name="your choice" or SDA> > show proc/locks so that I can see an example resource name? OK. On node SKYWAY I did: SKYWAY $ create x.x This is a test This is a test and on second thought did a control-T to get the process name: SKYWAY::PARRIS 12:59:30 CREATE CPU=00:00:00.20 PF=746 IO=415 MEM=188 and then just left it hanging there. In another session on the same node: SKYWAY $ sh us parris/full OpenVMS User Processes at 12-JUN-2003 12:31:05.64 Total number of users = 1, number of processes = 3 Username Node Process Name PID Terminal PARRIS GALXY1 PARRIS 248105C1 TNA100: PARRIS SKYWAY PARRIS 2A800514 TNA8: PARRIS SKYWAY _TNA9: 2A800515 TNA9: Ignoring the session on another node, and looking for the matching process name "PARRIS", we know the process ID of interest is 2A800514. (This other session we're using must be 2A800515.) SKYWAY $ anal/sys OpenVMS (TM) Alpha system analyzer SDA> set proc/id=2A800514 SDA> show proc/chan Process index: 0114 Name: PARRIS Extended PID: 2A800514 -------------------------------------------------------------------- Process active channels ----------------------- Channel CCB Window Status Device/file accessed ------- --- ------ ------ -------------------- 0010 7FBF0000 00000000 DSA99: 0020 7FBF0020 827DD040 $1$DGA149:[VMS$COMMON.SYSEXE]CREATE.EXE;1 0030 7FBF0040 824AD200 $1$DGA149:[VMS$COMMON.SYSLIB]LIBOTS.EXE;1 (section file) 0040 7FBF0060 00000000 Busy TNA8: 0050 7FBF0080 824AD180 $1$DGA149:[VMS$COMMON.SYSLIB]LIBRTL.EXE;1 (section file) 0060 7FBF00A0 00000000 TNA8: 0070 7FBF00C0 82820F80 DSA99:[PARRIS]X.X;3 0090 7FBF0100 824C21C0 $1$DGA149:[VMS$COMMON.SYSEXE]DCL.EXE;1 (section file) 00A0 7FBF0120 824AD000 $1$DGA149:[VMS$COMMON.SYSLIB]DCLTABLES.EXE;365 (section file) Total number of open channels : 9. We see the open channel to the file X.X. (Guess how many times I tried the $CREATE command before I found what I was looking for... :-) ) SDA> show proc/lock Process index: 0114 Name: PARRIS Extended PID: 2A800514 -------------------------------------------------------------------- %SDA-I-NOPRLOCK, no locks taken out by this process SDA> Uh-oh, this isn't going to be easy. The locks aren't owned by the process. Must be kept by the XQP. We'll have to go fishing. Most resource names associated with files use some form of the File ID, so let's find that out: SKYWAY $ dir/file_id x.x Directory USRD:[PARRIS] X.X;3 (162261,1,0) X.X;2 (162260,1,0) X.X;1 (162259,1,0) Total of 3 files. $DIRECTORY gives the File ID as (File Number, Sequence number, Relative Volume Number). These values are in decimal. SDA will display them in hexadecimal. SKYWAY $ x = 162261 SKYWAY $ show sym x X = 162261 Hex = 000279D5 Octal = 00000474725 So the hex value of the File Number will be 0279D5. The RVN is 00 (we're not on a Bound Volume Set), and the Sequence Number will be 0001. In memory, a File ID is stored in an odd manner, because it was extended at one time. The order as stored is: File number extension (top byte), Relative Volume Number (1 byte) File sequence number (2 bytes), and low-order 2 bytes of the File Number, which would appear in order in our case as 02 00 0001 79D5 . Another way the File ID may be represented in lock names is the Lock Basis, which discards the Sequence Number and fits the RVN and contiguous File Number into a single longword: RVN (1 byte), File number (3 bytes), which would appear in memory as 00 0279D5 . The disk volume name often appears in resource names, so I need to know what that is: SKYWAY $ show dev usrd Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA99: Mounted 0 USERDISK1 1204379 2 10 $10$DUA962: (GALXY1) ShadowSetMember 0 (member of DSA99:) $10$DUA963: (GALXY1) ShadowSetMember 0 (member of DSA99:) So the volume name is "USERDISK1". I pop back into SDA, and do: SKYWAY $ ANAL/SYS SDA> SET OUTPUT TEMP.FILE SDA> SHOW LOCKS/ALL SDA> EXIT and then search TEMP.FILE for the volume name and File ID, keeping in mind that they may be split across lines or fields in SDA's output. Since the File ID and Lock Basis have different formats, searching for the low-order two bytes (79D5) has a better chance of success. "RDISK1" proved to be a good string to search for the volume name. I didn't find any RMS locks (probably because this file is not open for shared access?) but did find some associated XQP locks: --- Lock id: 2E00445D PID: 00000000 Flags: VALBLK CONVERT NOQUEUE Par. id: 00000000 SUBLCKs: 0 SYNCSTS NOQUOTA CVTSYS LKB: FFFFFFFD.773B5880 BLKAST: 81910158 Priority: 0000 Granted at EX 00000000-FFFFFFFF RSB: FFFFFFFD.775C6480 Resource: 53556124 42313146 F11B$aUS Status: NOQUOTA VALBLKR VALBLKW Length 22 20314B53 49445245 ERDISK1 Kernel mode 00000002 79D52020 Õy.... System 00000000 00000000 ........ Local copy --- Referring to the "Lock and Resource Usage by OpenVMS Components" appendix in the IDSM, this one looks like a File Access Arbitration Lock. Its resource name is of the form F11B$a and it's a root lock (see, the parent Lock ID is zero), system-owned, kernel mode, EXclusive mode lock. Here's another: --- Lock id: 29004471 PID: 00000000 Flags: VALBLK CONVERT SYNCSTS Par. id: 01000CA4 SUBLCKs: 0 CVTSYS LKB: FFFFFFFD.77452A80 BLKAST: 00000000 Priority: 0000 Granted at NL 00000000-FFFFFFFF RSB: FFFFFFFD.7713D380 Resource: 79D57324 42313146 F11B$sÕy Status: NOQUOTA VALBLKR VALBLKW Length 10 00000000 00000002 ........ Kernel mode 00000000 00000000 ........ System 00000000 00000000 ........ Process copy of lock 2400A67D on system 00010053 (GALXY2) --- This appears to be a File Serialization lock, and its resource name is of the form F11B$s. Note that it has a Parent Lock with Lock ID 01000CA4 -- let's look at that: --- Lock id: 01000CA4 PID: 00000000 Flags: CONVERT SYNCSTS CVTSYS Par. id: 00000000 SUBLCKs: 13 LKB: FFFFFFFD.772D5080 BLKAST: 818D57E0 Priority: 0000 Granted at CR 00000000-FFFFFFFF RSB: FFFFFFFD.77349B80 Resource: 53557624 42313146 F11B$vUS Status: NOQUOTA VALBLKR VALBLKW Length 18 20314B53 49445245 ERDISK1 Kernel mode 00000000 00002020 ...... System 00000000 00000000 ........ Process copy of lock 01008C3D on system 00010053 (GALXY2) --- This looks to be a Volume Allocation Lock, with a resource name of the form F11B$v. This is a root resource (its parent Lock ID is zero), and our lock is one of the 13 sub-locks. You could probably use either of these two paths, but it looks like the easiest lock for you to use is probably the File Access Arbitration Lock, since you don't have to dig down a level and sift through several sub-locks to find that.