charliep@polaris.UUCP (Charlie Perkins) (11/22/85)
========= Are you tired of just tossing all the articles in your junk repository just because it's too much hassle to clean 'em up? Do you really want to make sure that there is EVEN MORE news available to your users? Well, then process_junk is just the thing you need. I have been working on this program very sporadically for a long time, and it seems to be pretty reliable. You will probably want to modify certain things about it, not least the shell variables at the tops of the programs like $LIB, etc. You may want to modify it so that junk is kept around less often than I keep it. The "main" program is "process_junk", which calls "modactive" and "getnewsgps". The latter two programs are much less useful by themselves, and could reasonably become C programs if speed becomes an issue. One general area that could be improved is to add locking so that these scripts could be run without disabling the news. One of the good things that these programs do is handle directories with many files correctly. ========= Arch_oldnews creates "nice" (but BIG) output suitable for printing out on a line printer. I use it to keep hardcopy listings of the news articles when I expire them, so that conceivably people could search through the listings to find interesting articles and retrieve them from the tapes. Anyway, it is useful. This program grew to about 5 times its original size and could very reasonably become a C program now. ========= Many, many times I have discovered TM files remaining in our uucp spool directory resulting from incomplete uucp sessions. Moreover, a significant minority of those files contained information that was never retransmitted, for reasons that I cannot undestand. I am a fanatic about not losing data, so I wrote the following programs to make maximum use of the incomplete TM files. This has the effect of sometimes duplicating mail that WAS eventually retransmitted correctly, but my users don't mind that at all. Duplicate news articles are later recognized as such. When all the articles are retrieved from the TM files, they can be moved to the junk directory and processed using "process_junk" which I have previously described. The files are deTM, deTMunbatch.c, and mv2junk. deTM does not autmatically invoke mv2junk so that it can work without having to lock the news files. mv2junk just has the effect of transferring deTM's results into the junk news directory so that process_junk can get to it. I would recommend at least reading the comments in deTM before trying to run it. deTM_unbatch is a C program, it was too crappy to do as a shell script. I would be willing to install #define's for portability if anybody wants to contribute them. deTM_unbatch has the effect of breaking down a batched news file into its constituent articles. ============================================================ I will be happy to distribute bug fixes and/or improvements if they are sent to me. -- Charlie Perkins, IBM T.J. Watson Research philabs!polaris!charliep, perk%YKTVMX.BITNET@berkeley, perk.yktvmx.ibm@csnet-relay