Comments on continuing to provide support for RN/RRN

[G. Roderick Singleton]

In article <4770 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>>I'm glad you've enjoyed success with trn; but I have not.  Under ISI4.3
>>mthreads blows up rather dramatically and chews up all available disk space.
>
>That's "mthreads", not "trn".  Did you try not running "mthreads" and
>using "trn" anyway?  It's supposed to essentially act as "rn" on
>newsgroups without ".thread" files.
>

But mthreads is part of the trn suite so can't see how one can separate
them.  In other words,  there is no reason to have trn when the code that
creates the thread database doesn't work well and every reason to keep rn as a
separate entity.

I originally installed trn with a link to rn; but, after multiple fiascos,
I decided that known working code was a better choice.  I will admit that
trn as rn appeared to work with one exception, that of handling cross-posted
articles as well as the real rn.

>(I.e., keeping RN and TRN separate may not be necessary to avoid this
>problem.)

Perhaps but we use trn because of its threading and the extra overhead of
for this feature which is compiled in may well dictate keeping them separate.

Still I liked it when it ran.  Now, can anyone point me to more robust
mthread code?  I'll gladly return to having my sites exclusively trn when
corrections appear.

On yet another note, my mail to author bounced rather badly but I'd
still like to set up communications with regard to solving this
problem.  So if you're reading this, please reply in  e-mail via a path
from my .signature.

Cheers,
ger
-- 
G. Roderick Singleton, System and Network Manager, JTS Computers 
{yunexus | uunet | geac | torsqnt}!gerry at jtsv16.jts.com