Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!execu!sequoia!attdso!tim From: tim@attdso.att.com (Tim J Ihde) Newsgroups: news.software.b Subject: Cnews on 3B2/600 Message-ID: <1989Jun22.215559.20578@attdso.att.com> Date: 22 Jun 89 21:55:59 GMT Reply-To: tim@attdso.att.com (Tim J Ihde) Organization: AT&T DSO-HQ, Morristown, NJ Lines: 51 I've gotten C-news up and running on our 3B2/600 running System V 3.1.1. Before I go any farther, let me say that I'm quite impressed with the overall package, and I appreciate the time and effort that you guys have obviously put into it. With a lead in like that, you can tell I've had a problem or two. First of all, there was an initial problem with relaynews and permissions. The program could not create the lockfile needed to post a new article. I ended up removing the call to setids(), and now it seems to operate properly with relaynews setuid to news. Secondly, I've noticed that the L option in the sys file does not seem to work properly. I've the following line in my sys: LocalLog:!to.all,all,all.all/all,!ihave,!sendme:L:/bin/rmail news The intent is to mail any locally created articles to news. The !to.all at the beginning was necessary to exclude the ihave/sendme articles to another machine. However, I find that I am also mailed any article created on a machine one hop away from mine; so the L is acting like L1. I tried explicitly stating L0; the result was the same. The third, and most serious problem, has to do with performance on ihave/sendme. Before I set up C news, I was using B 2.11 with the dbz.c file simulating the dbm library. This was very quick with both normal batches and with ihave/sendme's. With C news, I've found that the batches are processed at least as fast as before. However, the ihave/sendme's are now almost as bad as they were with B 2.11 _without_ the dbz.c -- read unacceptably slow. It takes almost two hours to process an ihave with 400 message id's, on a fairly empty machine. I've recompiled relaynews using dbz.c instead of Henry's dbm.c with similar results. My question here is: is this expected, or have I set a wrong option somewhere in build? With a performance difference this great, I'm thinking about dropping ihave/sendme entirely and just rejecting lots of articles as duplicates. I'm getting a full feed from two machines, one as straight batches and the other as a backup with ihave/sendme, both via 2400 baud uucp (and both fairly local calls). Any suggestions are appreciated. tim -- Tim J Ihde INTERNET: tim@attdso.att.com (201) 898-6687 UUCP: att!attdso!tim "First, you shall remove all the bugs. Then, you must cut down the mightiest tree in the forest, with . . . a herring!" -- the Supervisor who says "Ni!"