From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 19-MAR-1994 14:18:49.44 To: EVERHART CC: Subj: Re: Q: VMS Lock Manager and Sublocks. How? From: buczek@fhi-berlin.mpg.de (Donald Buczek) X-Newsgroups: comp.os.vms Subject: Re: Q: VMS Lock Manager and Sublocks. How? Message-Id: <1994Mar16.143159.8096@rz-berlin.mpg.de> Date: 16 Mar 94 14:31:59 +0100 Organization: Fritz-Haber-Institut der MPG,Berlin Lines: 202 To: Info-VAX@CRVAX.SRI.COM X-Gateway-Source-Info: USENET In article <01H9GCAEHUV68WWLZM@Darwin.CMH.McMaster.CA>, "Andrew Sackett, Information Services X 5150" writes: > I posted this once before and got absolutely 0 response. I still haven't > figured it out. Any gurus out there? > > H/W: VAX 6410 model 159 > O/S: VMS 5.5-1 > LANG: VAX C V3.2 > FACIL: VMS Lock Manager It seems to work as expected on a 4000-VLC , VMS A5.5-2HW , VAX C 3.2 I don't think there is such a bug in the lock manager in other versions (if it were, you had other problems), so I didn't try to redo my test with your version. > [...] > The locks are originally requested at NULL mode, and then converted up to the > requested mode. > > From what I can see in the VMS System Services Reference, I have just sest up > sublocks according to the following table: > > Lock Parent > ==== ====== > LOCK_0 none > LOCK_1_x LOCK_0 > LOCK_1_y LOCK_0 > LOCK_2_x_a LOCK_1_x > LOCK_2_x_b LOCK_1_x > LOCK_2_y_a LOCK_1_y > LOCK_2_y_b LOCK_1_y > > So, I requested all those locks. Then I used SDA in another window to > examine the locks for that process. All those locks were, in fact, granted. > They were granted at the appropriate modes. But the SDA reports showed > Sublocks: 0 for all of them! The appended C program does, what you want. SDA shows 2 sublocks for LOCK_0 and LOCK_1_*. > [...] > If sublocks shows up as 0 in SDA, does that mean that VMS is not doing the > 'must own parent lock at appropriate mode' type checks? If SDA says, a lock has no sublocks, it probably doesn't have any. I don't know, where you got the 'must own parent lock...' quote. The parent lock must be granted before a sublock will be granted. Note however, that the required lock-mode of the parent lock is a concern of the application, not the lock manager. It will allow an EX sublock, when the parent lock ist granted at NL. Probably the 'mode' in you quote refers to the processor mode (which qualifies the namespace anyway) and not to the lock mode. > How can I get Sublocks to show a nuamber other than 0? Fix your bugs. :-) Send me you source if you want. > I noticed in the description of the parent lock id argument to SYS$ENQ(), that > that argument was ignored for new locks. Why do they do this? I couldn't find this statement in my version of the documentation. In my System Service Reference manual I read: -- If you do not specify this [...] the lock does not have a parent lock. This argument is optional for new locks and is ignored for lock conversions. -- > If it's > ignored for new locks, then how do you insert a lock into the hierarchy? How > can a lock be 'addopted'? It is not ignored at creation time, whatever your manual says. There is no supported way to 'reparent' a lock after it is created. > [...] -------- snip ---- snap --- C examples follows -------------- #include #include #include #include typedef unsigned int ULONG; typedef unsigned short UWORD; ULONG enq(char *resname,ULONG parent) /* enqw at NL, return lkid */ { ULONG status; struct {UWORD status;UWORD reserve;ULONG lkid;} lksb; struct dsc$descriptor_s resname_d = {strlen(resname),DSC$K_DTYPE_T,DSC$K_CLASS_S,resname}; status = sys$enqw(0,LCK$K_NLMODE,&lksb,0,&resname_d,parent,0,0,0,0,0); if (!$VMS_STATUS_SUCCESS(status)) lib$stop(status); if (!$VMS_STATUS_SUCCESS(lksb.status)) lib$stop(lksb.status); return(lksb.lkid); } void convert(ULONG lkid,ULONG mode) /* convert to new mode */ { ULONG status; struct {UWORD status;UWORD reserve;ULONG lkid;} lksb = {0,0,lkid}; status = sys$enqw(0,mode,&lksb,LCK$M_CONVERT,0,0,0,0,0,0,0); if (!$VMS_STATUS_SUCCESS(status)) lib$stop(status); if (!$VMS_STATUS_SUCCESS(lksb.status)) lib$stop(lksb.status); } main() { ULONG status; ULONG lock_0 ULONG lock_1_x,lock_1_y ULONG lock_2_x_a,lock_2_x_b,lock_2_y_a,lock_2_y_b; lock_0 = enq("LOCK_0",0); lock_1_x = enq("LOCK_1_x",lock_0); lock_1_y = enq("LOCK_1_y",lock_0); lock_2_x_a = enq("LOCK_1_x_a",lock_1_x); lock_2_x_b = enq("LOCK_1_x_b",lock_1_x); lock_2_y_a = enq("LOCK_1_y_a",lock_1_y); lock_2_y_b = enq("LOCK_1_y_b",lock_1_y); convert(lock_0,LCK$K_EXMODE); convert(lock_1_x,LCK$K_EXMODE); convert(lock_1_y,LCK$K_EXMODE); convert(lock_2_x_a,LCK$K_EXMODE); convert(lock_2_x_b,LCK$K_EXMODE); convert(lock_2_y_a,LCK$K_EXMODE); convert(lock_2_y_b,LCK$K_EXMODE); { char b[1]; struct dsc$descriptor_s t={sizeof(b),DSC$K_DTYPE_T,DSC$K_CLASS_S,b}; static readonly $DESCRIPTOR(p,"> "); status = lib$get_input(&t,&p); if ( (!$VMS_STATUS_SUCCESS(status)) && (lib$match_cond(&status,&LIB$_INPSTRTRU)!=1) ) lib$stop(status); } } ----------------------------------------------------------------- -------- snip ---- snap --- extracts from SDA output follows -------------- Lock data: Lock id: 310027AB PID: 002A0026 Flags: CONVERT Par. id: 00000000 SUBLCKs: 2 LKB: 8123E680 BLKAST: 00000000 PRIORTY: 0000 Granted at EX 00000000-FFFFFFFF Resource: 0000305F 4B434F4C LOCK_0.. Status: Length 06 00000000 00000000 ........ User mode 00000000 00000000 ........ Group 304 00000000 00000000 ........ Local copy -- Lock data: Lock id: 0B00090A PID: 002A0026 Flags: CONVERT Par. id: 310027AB SUBLCKs: 2 LKB: 811A9000 BLKAST: 00000000 PRIORTY: 0000 Granted at EX 00000000-FFFFFFFF Resource: 785F315F 4B434F4C LOCK_1_x Status: Length 08 00000000 00000000 ........ User mode 00000000 00000000 ........ Group 304 00000000 00000000 ........ Local copy -- Lock data: Lock id: 1700029E PID: 002A0026 Flags: CONVERT Par. id: 0B00090A SUBLCKs: 0 LKB: 81282180 BLKAST: 00000000 PRIORTY: 0000 Granted at EX 00000000-FFFFFFFF Resource: 785F315F 4B434F4C LOCK_1_x Status: Length 10 00000000 0000615F _a...... User mode 00000000 00000000 ........ Group 304 00000000 00000000 ........ Local copy ----------------------------------------------------------------- -- Donald Buczek buczek@FHI-Berlin.MPG.DE "It's a Boo..."