Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj From: rbj@uunet.UU.NET (Root Boy Jim) Newsgroups: news.software.b Subject: Re: Duplicate articles from B news site - would C news help ?? Message-ID: <113417@uunet.UU.NET> Date: 4 Dec 90 01:42:59 GMT References: <1990Nov22.175142.18296@zoo.toronto.edu> <16070@bfmny0.BFM.COM> Organization: UUNET Communications Services, Falls Church, VA Lines: 75 In article <16070@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >If you think you're seeing an unusual number of duplicate articles from >UUNET: you are! The problem is with their software, not yours. They >are working on it, but as of this writing it's not fixed yet. At last the story can be told! We recently moved news from the Sequent to the Pyramid. In the process, we used dbz instead of dbm. DON'T DO THIS UNLESS UNLESS YOU LIKE TO DEBUG SOFTWARE! EVEN IF YOU *ARE* THE ADVENTURESOME TYPE, DON'T TRY THIS ON A SYSTEM THAT CAN RETRANSMIT DUPLICATE ARTICLES INTO THE NETWORK! Here is a rundown on the problems. First, you must call DBMCLOSE before you exit in order to flush all buffers. If you don't, the history file will be updated, but the database won't be, and all new articles will not be found. The second problem is that dbz uses stdio rather than read/write. Stdio writes full buffers, not just the data you're interested in. B news runs many copies of inews/rnews -U, while C news runs one inews/rnews -U with the history buffer in core, so no one trips over each other. Actually, I'm not exactly sure why the preceding matters, unless data read before a lock is obtained is rewritten. Ask Rick or Henry. In any case, we are taking responsibility for it. Where it counts. In the pocket. Below is Rick's message to all our paying customers: % From rick Sat Dec 1 12:58:24 1990 % Received: by uunet.UU.NET (5.61/1.14) % id AA07478; Sat, 1 Dec 90 12:52:15 -0500 % Date: Sat, 1 Dec 90 12:52:15 -0500 % From: rick (Rick Adams) % Message-Id: <9012011752.AA07478@uunet.UU.NET> % To: customer-list % Subject: duplicate news % Status: RO % % % Over the last week or so, we have had problems with duplicate news % articles. % % In an effort to improve performance, we moved news processing to a % separate machine. As part of the move, we recompiled Bnews with dbz % instead of dbm. This allegedly would get us a large speedup. % % Well, it did, but it also accepted a lot of duplicates! % % I believe I've fixed the duplicate problem. (24 hours so far without % duplicates) % % There may be some still queued for transmission, but we should not be % queueing up any more duplicates. % % Unfortunately, we have no way of telling how many duplicates were erroneously % transferred to your sites. % % We will be happy to credit you for the transfer time for the useless % articles. However, we can't calculate that credit. % % So, if you would like to be credited for the duplicate news you were % sent, send email to uunet!billing with your estimate of wasted connect % time and the credit you would like. % % This credit will be reflected on your 1/1/91 invoice. % % Sorry for the trouble. % % --rick -- Root Boy Jim Cottrell Close the gap of the dark year in between