From:	ADVAX::"mcnc!VM1.NoDak.EDU!toon%NEWS.SARA.NL"  5-FEB-1991 16:00:11.76
To:	Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
CC:	
Subj:	System wide NEWS_LOCK lock not dequeued properly ?

Received: by ADVAX.DECnet (utk-mail11 v1.5) ; Tue, 5 Feb 91 15:58:28 EST
Received:  from mcnc by ge-dab.GE.COM (5.65a+/GE-DAB 1.15) with UUCP
	id AA10007 for ; Tue, 5 Feb 91 15:12:47 -0500
Received: from VM1.NoDak.EDU by mcnc.mcnc.org (5.59/MCNC/6-11-90)
	id AA24907; Tue, 5 Feb 91 14:25:34 -0500
	for ARISIA.DNET.ge.com!EVERHART
Message-Id: <9102051925.AA24907@mcnc.mcnc.org>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 3999; Tue, 05 Feb 91 13:24:39 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 6872; Tue, 05 Feb 91 13:24:38 CST
Date:         Tue, 5 Feb 91 15:11:40 GMT
Reply-To: mcnc!VM1.NoDak.EDU!toon%NEWS.SARA.NL
Sender: ANU-NEWS Discussion <ANU-NEWS@VM1.NoDak.EDU>
From: mcnc!VM1.NoDak.EDU!toon%NEWS.SARA.NL
Subject:      System wide NEWS_LOCK lock not dequeued properly ?
To: Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
 
        We're running ANU-NEWS 6.0-1 (14-Nov-90) on VMS 5.3-1 in a
LAVc cluster consisting of 1 VAX 11/785 (boot member of) 3 VAX-
station 2000's and 4 VAXstation 3100's.
 
        We experienced a strange problem in the weekend of 26/27th
of January. We do the NEWS.ITEMS, NEWS.GROUPS and HISTORY file
compaction in the weekend, and this was the first occasion I had
given the SYSLCK privilege to NEWSMGR and installed NEWS with
SYSLCK (in addition to SYSPRV).
 
        In the course of the Monday following this weekend I noticed
we received no new NEWS, but I was not alarmed particularly until
a collegue said that he couldn't access NEWS anymore. It turned
out that the system (and in our case CLUSTER) wide lock set out
by NEWGRPFILE and NEWITMFILE was still in effect, ALTHOUGH THE
BATCH JOB (AND THEREFOR THE PROCESS) WHICH HAD RUN THESE IMAGES
HAD LONG GONE. Booting the cluster node on which the skim job
had run was the only remedy I could think of (not a major disaster,
since it is my VAXstation 3100 - these stations are the fastest
VMS system around here :-).
 
        My question (quite obvious): Has anyone experienced this
behaviour ? What is its cause ? I'm not up to quoting the System
Service Manual and the VAX/VMS Internals and Data Structures book
here, but my idea of the locking services is, dat a lock is released
(depending on access mode) on image exit (user mode) or process
exit (all other modes). Bug in VMS ?
 
        I decided that I didn't want to stand the chance a second
weekend (getting behind on NEWS for two days is desastrous -
it took us a whole week to catch up, with a lot of manual
intervention - read: people hanging around until late in the
evening to start skim / add jobs in the correct order to prevent
overflowing the RA81 NEWS resides on).
 
        Therefor I took a close look to the routines in NEWGRPFILE
and NEWITMFILE that take out the locks and those (non-existant)
that release the lock. Although I am still convinced that VMS
should release the lock on process exit, there is something disturbing
to the sys$enq call in the above files. To quote:
 
sys$enq(0,LCK$K_EXMODE,&lksb,LCK$M_SYSTEM,&lock_desc,0,gotlock,0,0,0,0);
        1      2         3         4          5      6    7    8 9 10 11
 
Now, according to the System Services Manual, argument 10 should be the
access mode (passed by VALUE). According to SYS$LIBRARY:PSLDEF.H,
0 corresponds to PSL$C_KERNEL. If we might believe the manual, in
ordinary user code, you'd still not get a kernel mode lock, but one
with the maximum of (your current access mode, the requested access mode).
Well, to make a long story short, I changed argument 10 to PSL$C_USER
and added a sys$deq(lksb.lksb_l_lock_id, 0, PSL$C_USER, 0); line to
the routine exit_call.
 
        This weekend (3/4th of February) I experienced no problems.
--
 
Toon Moene, SARA - Amsterdam (NL)
Internet: TOON@SARA.NL
 
/usr/lib/sendmail.cf: Do.:%@!=/
