rrn@lib.tmc.edu (Stan Barber) (11/26/90)
If you are having problems with Patch 50 and ndir.c, please use the version just posted to these groups. That should address the problem. I am debating on continuing to post patches to rn/rrn. It seems I always run into a case where the patch fails on someone's version of rn/rrn. While I am sure it is very frustrating to have this happen to your copy, imagine being on the receiving end of all that frustration mail. This is why I have always provided full kits available via anonymous ftp whenever I have done a patch. That way, you can have exactly what I have. Now, I know this is not a complete answer for those of you not on the internet. However, there are anonymous uucp sites around that provide them. I have also thought of building a specific archive-server just for rn/rn and nntp so people could avoid the frustration of having the patches fail. Such a server will come on line by the end of the year mostly to deal with nntp requests. The future of rn/rrn is uncertain. With the success of trn, there may be no need to continue to maintain rn/rrn. Then again, they may merge. This is largely Wayne Davidson's decision. Hopefully, he will be well enough soon to share his views with me on these issues. [Note: He was in an auto accident recently.] I am sure the blame is mine for all these problems. I appologize for any frustration I may have caused you. Your comments on these matters are welcome. Please use the "rrn@lib.tmc.edu" address.
gerry@jts.com (G. Roderick Singleton ) (12/04/90)
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.
This is most inconvenient and, thanks to you RN provided a safe clean
fallback path. My users like RN just fine and I see no reason to handle
TRN. Please keep RN separate.
Reagrds,
ger
--
G. Roderick Singleton, System and Network Manager, JTS Computers
{yunexus | uunet | geac | torsqnt}!gerry@jtsv16.jts.comguy@auspex.auspex.com (Guy Harris) (12/12/90)
>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. (I.e., keeping RN and TRN separate may not be necessary to avoid this problem.)
gerry@jts.com (G. Roderick Singleton ) (12/15/90)
In article <4770@auspex.auspex.com> guy@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@jtsv16.jts.com
tchrist@convex.COM (Tom Christiansen) (12/17/90)
I can't explain why you have problems with mthreads, nor why you can't get mail to the author, as I've neither of these problems, but let me explain the crosspost thing. When you exit a thread menu and everything is considered read, it does so using the catchup code, which is MUCH faster than calculating xrefs. That's why you think that crossposting isn't working. It got me, too, but Wayne Davison explained it to me. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
gerry@jts.com (G. Roderick Singleton ) (12/24/90)
In article <111558@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I can't explain why you have problems with mthreads, nor why >you can't get mail to the author, as I've neither of these >problems, but let me explain the crosspost thing. When you [cross-post explanation deleted] Tom, From your comment about mthreads I gather there's at least one other with problems making mthreads behave, at least ,other than myself. Like this other person, I've also had trouble reaching Wayne, basically for the same reason (i.e. mail gets bounced). I would appreciate your help in obtaining an answer/solution to my specific problem by forwarding this to Wayne and perhaps having a look yourself since you're having success using the trn package complete with mthreads. Here's my complaint: mthreads periodically behaves in bizarre manner and completely fills the disk partition where the error log resides. As you can imagine this causes a great deal of consternation at my site. Further whilst exhibiting its strange behaviour, mthreads seems to be generating interrupts of its own which furthers exacerbates the problem. I gave a slightly more detail in my original message, an excerpt from the log file, but I was obliged to remove all the trn/mtrheads logs when I switched back to rn. Now for the rest of you, while this message may appears to explicitly address Tom, it is really general a cry for help from any that can offer assistance. Please e-mail me and I will summarize any/all responses that specifically offer a solution. Thanks Tom for helping and Wayne for providing a basically decent replacement for rn. Regards, ger -- G. Roderick Singleton, System and Network Manager, JTS Computers {yunexus | uunet | geac | torsqnt}!gerry@jtsv16.jts.com
dewey@sequoia.execu.com (Dewey Henize) (12/26/90)
] ]Tom, ] ]From your comment about mthreads I gather there's at least one other ]with problems making mthreads behave, at least ,other than myself. ]Like this other person, I've also had trouble reaching Wayne, basically ]for the same reason (i.e. mail gets bounced). ] ].... ]Here's my complaint: mthreads periodically behaves in bizarre manner and ]completely fills the disk partition where the error log resides. As you ]can imagine this causes a great deal of consternation at my site. Further ]whilst exhibiting its strange behaviour, mthreads seems to be generating ]interrupts of its own which furthers exacerbates the problem. ] I had a lot of trouble on both the machines I administer getting this started. After a couple days fooling with it (thank goodness most of my users had split for the holidays), I was able to track things down so far as to determine it was apparently hanging forever (using CPU & I/O) trying to get caught up or something on the junk directories. They both had huge numbers for the article numbers and they both had a lot of articles in the directories as well. I don't know that that is what the problem was, but... ].... ] ]Now for the rest of you, while this message may appears to explicitly ]address Tom, it is really general a cry for help from any that can ]offer assistance. Please e-mail me and I will summarize any/all ]responses that specifically offer a solution. ] What I ended up doing was to mv the junk directories and remove them from the active file, replacing the entry in the active file with a phone of junk 000000 000000 y (however may zeros that was to match), and crank it up one more time. This time it got through fine and things have been cooking along just fine since. Whether the number of the articles was the culprit, the name/number that junk had gotten up to, or some other factor that fell out in the wash I honestly don't know at this point. Nonetheless, it worked and now I'm thoroughly hooked on trn - I find I actually get through with my newsreading and still have some time left over to do what my company pays me for! :-) I admit, though, that the ability to not even see some of the garbage posts is really what makes me such a strong and vocal proponent. <grin> Heck, I can even get through the news heirarchy now! ]Thanks Tom for helping and Wayne for providing a basically decent ]replacement for rn. ] Ditto and me too and all that! ]Regards, ]ger Now, since I said this much, is there any way to have trn recognize crossposting at the thread selection level? So that something like the rn 'Jy' macro that kills across groups would be available? I *know* that it's working correctly now, and I'm not complaining really, I'm just a tad spoiled by that old macro I got off the net and would love to have the equivalent 'up' one level at threads instead of either seeing the same crossposts or having to go into reading level to use the 'Jy' to junk. Hope this helps, and once again thanks to the authors for a neat and, amazingly useful, package. Dew -- | Execucom and I often have different ideas. THESE are mine, ok? Ok. | | dewey@execu.com or uunet!sequoia!dewey | |Don't reword the question into such generality that it appears absurd, that's| |a puerile trick. -Barry Shein | But this IS Usenet!! - me |