From:	ADVAX::"mcnc!VM1.NoDak.EDU!glass%VIXVAX.MGI.COM" "William H. Glass" 31-JAN-1991 23:26:47.53
To:	Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
CC:	
Subj:	Re: Junked articles from parallel batches

Received: by ADVAX.DECnet (utk-mail11 v1.5) ; Thu, 31 Jan 91 23:25:29 EST
Received:  from mcnc by ge-dab.GE.COM (5.61/GE-DAB 1.15) with UUCP
	id AA28695 for ; Thu, 31 Jan 91 23:04:46 -0500
Received: from VM1.NoDak.EDU by mcnc.mcnc.org (5.59/MCNC/6-11-90)
	id AA00321; Thu, 31 Jan 91 14:56:22 -0500
	for ARISIA.DNET.ge.com!EVERHART
Message-Id: <9101311956.AA00321@mcnc.mcnc.org>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8546; Thu, 31 Jan 91 13:55:28 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 5478; Thu, 31 Jan 91 13:55:26 CST
Date:         Wed, 30 Jan 91 02:02:06 GMT
Reply-To: "William H. Glass" <mcnc!VM1.NoDak.EDU!glass%VIXVAX.MGI.COM>
Sender: ANU-NEWS Discussion <ANU-NEWS@VM1.NoDak.EDU>
From: "William H. Glass" <mcnc!VM1.NoDak.EDU!glass%VIXVAX.MGI.COM>
Subject:      Re: Junked articles from parallel batches
To: Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
 
In article <1991Jan28.220754.5934@cerritos.edu>, tanner@cerritos.edu writes:
> Since I've started running batch adds in parallel, I get occasional junked
> articles with the reason "Cannot add to newsitem index file" (in the second of
> the three places the message occurs).  I assumed that it was a news.items
> record that was locked.  I looked at the code and now I'm confused.  What does
> itm_cachedate have to do with the index file?  I don't use /cache.
 
itm_cachedate is used to remember when an article was retrieved from a server.
You're right, you're not using it.  The code in question is looking to see
if the Message-ID of the article being added is already in the index file.
Normally, it shouldn't be there.  The code that you isolated is what handles
the case if the record is found.  In the case of a served node, there may be
an entry, but the cache date should be zero to indicate that the text of the
article isn't stored locally.
 
I believe that the key to your problem is that the status variable is not
being set correctly.  I suspect that because of the parallel adds, the program
has tripped over some special case of the second add failing.  The code that
you isolated is the normal place that this is detected.  However, the error
text "Cannot add to newsitem index file" is ultimately ignored if the status
code indicates that a duplicate record was the cause.  All we need to do is
get the proper value for status, and then you'll get the normal error for
a duplicate article.
 
Try the following one line change in do_new_item in NEWSUTILITY.C
 
     if ((status = sys$get(&itmrab)) & 1) {             /* modified */
       if (!newsitm.itm_cachedate) {
         time((time_t *) &newsitm.itm_cachedate);
         sys$update(&newsitm);
         savitm.itm_num = newsitm.itm_num;
         newsitm = savitm;
         }
       else {
         status &= 0Xfffffff;
         status += 0XB0000000;
         strcpy(no_new_item,"Cannot add to Newsitem index file");
         newsitm = savitm;
         continue;
         }
 
--
 
William H. Glass                        Internet: glass@mgi.com
Management Graphics, Inc.               Phone:    +1 (612) 854-1220
1401 E. 79th Street
Minneapolis, MN  55425
