From: utzoo!decvax!ittvax!swatt Newsgroups: net.news.b Title: Re: query about uurec Article-I.D.: ittvax.393 Posted: Thu Jul 22 17:43:20 1982 Received: Sun Jul 25 22:04:34 1982 References: sri-unix.2232 It may not be clear from the first few lines of my "gename.c", but if your system is not "ITTVAX" and you just compile gename.c without -DTSSEQ -DSEQHUNK=10, you will get exactly the same behavior as the original. This was perhaps a bit of overcaution on my part to make the old behavior the default. If you just use the -DTSSEQ flag, you will get base 62 sequence numbers, but (alas) still fetch them from the sequence file 1 at a time. An easy way to tell if the -DTSSEQ flag was in effect is: nm -g uux | grep _tstoa If the -DTSSEQ option is not defined, "tstoa()" is not compiled, in which case you can be sure the chunking option is not in effect. If the symbol is present, do: cat /usr/lib/uucp/SEQF uux foobaz!mumblefratz cat /usr/lib/uucp/SEQF which although uux will complain about unknown system "foobaz" will still force a "gename" call or two. By comparing the sequence file before and after you can tell what the chunk size is (NOTE: a normal uux call will generate ~6 "gename" calls). This is a rather long prelude to the totally unrelated conclusion that this is still not your problem, as uuxqt won't call "gename" unless an output file is specified; uurec doesn't call it at all; and uucico won't call it unless the "callback" flag is set in L.sys (or USERFILE, I forget which; for long and gory reasons, the callback feature just plain doesn't work anyway). Conclusion: if the "uurec" operation takes too long, look elsewhere than the UUCP system for the culprit. Previously Mark Horton (I think) has mentioned that if your news history file is large, inserting a new article will take a long time. Versions 2.8 (I think) and later of "expire" would correctly expire articles and re-write the history file to contain only those articles left in the system. I am not familiar with the uurec operation, so I really can't comment further. - Alan S. Watt (decvax!ittvax!swatt)