🚀 go-pugleaf

In article <fjp.042k@crystal.mv.com> fjp@crystal.mv.com (Frank Perricone) writes:
> In AmigaUUCP, when you run Trimnews, it just deletes old articles, but
> leaves the article numbering where it was.  The result is that you end up
> with numbers in the thousands fairly quickly, and they never seem to go
> down!  And when that happens, DNews becomes VERY slow.

No. DNews doesn't care in the least. At least current versions of DNews
don't. DNews goes from the highest article number it knows about, to the
value stored in the .next file minus one. And when doing a subscribe, it
examines all files in a directory, but not one-by-one.

> In an attempt to correct this, I wrote a renumber program which moves the
> numbers down, updating the .dnewsrc file and the .next file as it does.
> However, now I get an error message from BatchNews saying that files are
> missing.
>
> What I wonder is, why does BatchNews care?  I'm not feeding this stuff down
> to anyone else; my only link is to the place I got those files from in the
> first place.	Is this just an artifact of the way that messages are
> unpacked, or does it indicate a real problem?  Can I just ignore those
> messages?  If not, do I have to also update numbering in some other file,
> and if so, what?

If batchnews is reporting an error message, then you have SOMETHING
set up to feed back. This is dependent on the uulib:sys file.

> Alternately, can someone suggest a better newsreader that avoids these
> problems, and how to get it?	(I've asked this one before but my post may
> not have gotten out.)

Are you using the 1.17b4 DNews?

Try GRn. :)

There are others: Arn, Thor, etc.
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us