Date: Sun, 26 Feb 95 09:52:31 EST From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1995 #4 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Sun, 26 Feb 95 Volume 1995: Issue 4 Today's Topics: 1.12M comments Aliasing problem (2 msgs) cache module for history database file length limitation in uupc? rmail question SLIP & UUPC (4 msgs) that digest which just went out two more 1.12M questions uupc/extended 1.12m To subscribe to UUPC-Info-Digest, send the command in the body of a message to listserv@kew.com: subscribe uupc-info-Digest To signoff from UUPC-Info-Digest, use "signoff" instead of "subscribe". You can also send an "index" to the listserv to get an index of back issues and other files available for retrieval. ---------------------------------------------------------------------- Date: Thu, 23 Feb 1995 07:14:50 -0500 From: Help@kew.com Subject: 1.12M comments To: UUPC/Extended mailing list On Wed, 22 Feb 1995 21:02:36 -0500, "Michael D. Lawler" wrote: > I like the fromwho program, but would it be possible to add the extention > that is listed in the mailext option as a default to the end of the file > name? For example my extention is .spb, but fromwho aborts with the error > that it can not find j:/spool/mail/mdlawler even though my mail is in > j:/spool/mail/mdlawler.spb by default. fromwho was donated by Kai Uwe Rommel. I honestly don't have time to play with it, and am prone to delete it if people don't find it useful in its present form and can't contrubite updates. > There were both a uucp.com and > uucp.exe included which one should I use? Finally, I got a runtime error > when running the fromwho program with no arguments, but it went away and > for the life of me I can not reproduce it. uucp.com may blow with a stack error, in which case delete it and use uucp.exe. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 "A hobbit will get you through times of no bagels better than bagels will get you through times of no hobbit." - The Grey-eyed Elf ------------------------------ Date: Tue, 21 Feb 1995 17:43:06 -0600 (CST) From: cel@tenet.edu Subject: Aliasing problem To: UUPC/Extended mailing list Hello all, I believe I'm close to getting this to work. Incoming mail to my FQDN is finally being routed to my uucp feed. Now that it is arriving, it is bouncing to the root (ie, not being sent to the users on my network). The problem is that I would like to use the firstname.lastname as the mailing address for each user rather than the novell login name. Where do I make this association? Alias? Gateway.cfg? Real world user Cliff Lee would login to my novell network as 2lce and would like to use cliff.lee@cbs-engineering.com as an email address. From the error message in Rmail.log, I think this association is not complete. Where would I do this? What would the alias entry for this user look like? Contents of Rmail.log -------------------------- 02/21-16:53 RMAIL: UUPC/extended 1.12k (Dec 11 1994 12:33:55) 02/21-16:53 Bounce: Mail from cel@tenet.edu for cliff.lee failed, Invalid local address (not defined in PASSWD or ALIASES): cliff.lee 02/21-16:53 Delivering mail (773 bytes) from cel@tenet.edu to root Cliff Lee cel@tenet.edu "You can always make up a class, You can never make up a party!" ------------------------------ Date: Tue, 21 Feb 1995 20:30:37 -0500 From: uupcinfo@kew.com Subject: Aliasing problem To: UUPC/Extended mailing list On Tue, 21 Feb 1995 17:43:06 -0600 (CST), cel@tenet.edu wrote: > I believe I'm close to getting this to work. Incoming mail to my FQDN is > finally being routed to my uucp feed. Now that it is arriving, it is > bouncing to the root (ie, not being sent to the users on my network). > > The problem is that I would like to use the firstname.lastname as the > mailing address for each user rather than the novell login name. Where do > I make this association? Alias? Gateway.cfg? \uupc\aliases firstname.lastname: logname > Real world user Cliff Lee would login to my novell network as 2lce and > would like to use cliff.lee@cbs-engineering.com as an email address. From > the error message in Rmail.log, I think this association is not complete. firstname.lastname: logname cliff.lee: 2lce And, of course, add 2lce to the PASSWD file. > Where would I do this? What would the alias entry for this user look > like? > > Contents of Rmail.log > -------------------------- > > 02/21-16:53 RMAIL: UUPC/extended 1.12k (Dec 11 1994 12:33:55) > 02/21-16:53 Bounce: Mail from cel@tenet.edu for cliff.lee failed, > Invalid local address (not defined in PASSWD or ALIASES): cliff.lee > 02/21-16:53 Delivering mail (773 bytes) from cel@tenet.edu to root > > > Cliff Lee cel@tenet.edu > "You can always make up a class, > You can never make up a party!" > -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 To sign off from uupc-info, send the command "signoff uupc-info" in the body of a message to listserv@kew.com. DO NOT send this request to the list itself! For human assistance with the list itself, send mail to snuffles@kew.com. "I never met a bug I didn't like." - Will Rogers ------------------------------ Date: Sun, 19 Feb 1995 18:27:35 -0500 From: Software@kew.com Subject: cache module for history database To: UUPC/Extended mailing list Kai Uwe, Thanks kindly. I've added the caching support to the makefile. I have no idea as to what to use for a cache value on DOS. However, if the routines can be covert to use FAR cache memory (see dcpgpkt.c for examples) in 16 bit models, then most if not all news programs which use the history database could safely use a ~ 36 page cache in one segment. (I see the pages are allocated one at a time, but 64K is a nice round number anyway, and one likely to be available.) I'll make it configurable, and use a ~ 4 page cache in 16 bits for now, and a ~ 138 page cache for 32 environments. This all will be part of UUPC/extended 1.12m. On Sun, 19 Feb 1995 20:37:30 +0100, "Kai Uwe Rommel" wrote: > finally I found the time to add caching to the history database > index. I include the new rnews/cache.[ch] and a cache.dif for the rest > of the (minimal) changes. Except for the Makefile changes and a small > unrelated safety addition to expire.c, there are only changes to idx.c > (and one line to idx.h), including one also unrelated correction for > the redundant malloc call in idx.c > > The cache is finished except for two points: > > a) The cache size is currently hardcoded in idx.c (the call to the > cache_init functions gets the number of index pages - 1806 bytes > each - to be allocated for the cache). I have not yet made up my > mind how to configure it. One probably wants to make it either > adjustable by a new system.rc setting or by querying available > memory (optionally; in any case, a fixed cache size should be > possible too). I would like to leave this decision to you since it > is probably only a matter of a few lines for you to implement > this. For DOS, caching probably has to be disabled because of > memory limitations. > > b) No caching is performed yet for the data file (the above is for the > B-tree index file) but should be implemented too. I'll do this when > the next slot of spare time is available for it. :-) I think of > sequential read/write buffers of about 64k which will only help in > those cases when all records are touched sequentially (expire, > genhist, rnews when unpacking batches of new messages; in all other > cases, usually only a few records are read randomly). > > For testing the efficiency of the idx cache, I ran expire with four > different cache sizes of 64, 256, 512 and 1024 B-tree pages: > > 64 pages: > (1) expire: Purging news older than 02/05-20:47 (14 days) > (1) cache_exit: 14224 read and 13225 write I/O calls, hit rate 79% > (1) Total of 25809 articles, 4802 cross postings (63050967 bytes). > > 256 pages: > (1) expire: Purging news older than 02/05-20:51 (14 days) > (1) cache_exit: 4115 read and 5782 write I/O calls, hit rate 93% > (1) Total of 25809 articles, 4802 cross postings (63050967 bytes). > > 1024 pages: > (1) expire: Purging news older than 02/05-20:54 (14 days) > (1) cache_exit: 82 read and 1978 write I/O calls, hit rate 99% > (1) Total of 25809 articles, 4802 cross postings (63050967 bytes). > > 512 pages: > (1) expire: Purging news older than 02/05-20:59 (14 days) > (1) cache_exit: 1209 read and 3062 write I/O calls, hit rate 97% > (1) Total of 25809 articles, 4802 cross postings (63050967 bytes). > > Run time when executed with a local news spool reduced by about one > third in (data file caching should further reduce I/O), when executed > over the net, execution time reduced far more, naturally, for the > drastically reduced number of I/O calls. > > Let me know if anything looks strange or other questions arise ... > > Kai Uwe Rommel -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 "Erotic is when you use a spoonful, kinky is when you use the whole pint" - The Grey-eyed Elf ------------------------------ Date: Wed, 22 Feb 1995 06:48:20 -0500 From: Help@kew.com Subject: file length limitation in uupc? To: UUPC/Extended mailing list On Mon, 20 Feb 1995 23:51:29 -0700, "Walter J. Mack" wrote: > I was trying to get a mail which was 500 k bytes long (a uuencoded disk), > but after ~180kbytes, there were 10 consequtive errors and the connection > died. > uucico with -x10 revealed that with packet 360 (each packet being 512 bytes) > my end saw checksum and out of order packets. > > Is there a size limitation around 180kbytes for files transferred using > uupc? Is this limitation present in all versions of uupc? No, it's a bug if it happened. It sheds light on a known (unsolved) problem if it did happen from a checksum bug, but internally packets are counted modulo 8, so packet 360 is no different from packet 352, 368, 376, etc. If it didn't cost an arm and a leg, retry the transfer. It is more likely the problem occurred because of the known bug, which is the two systems have generically trouble resyncing after a failure because the resent packet appears out of order. That will be foxed _after_ ship the current release, 1.12m, which has enough changes in it (mostly to news) already to warrant release/testing while I continue to work on problems such as this. I've added you to our release annoucement release so you'll know when its available. -ahd- -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 This space for rent. ------------------------------ Date: Fri, 24 Feb 1995 12:03:18 -0600 (CST) From: cel@tenet.edu Subject: rmail question To: UUPC/Extended mailing list I have found that the files that are being placed in the F:\net\uucp\usr\spool\nuchat\X\ directory look like the following: U root nuchat F D.nuchatN004F I D.nuchatN004F C rmail cliff.lee I understand that the last line SHOULD read C rmail cliff.lee@cbs-engineering.com If I manually modify the file, all is well. However, my UUCP provider (sccsi.com) indicates that this is nonstandard. (ie not rfc compliant). Consequently, they have told me that they are not going to be able to make this addition to these incoming files. Is there an option somewhere to tell rmail (or whatever) to assume @cbs-engineering.com? Is there a way around this? Without it, uulan.exe distributes the mail to the root account only. Cliff Lee cel@tenet.edu ------------------------------ Date: Thu, 23 Feb 95 20:54:06 -0500 From: sysop@mome-raths.iac.net Subject: SLIP & UUPC To: UUPC/Extended mailing list Can anyone tell me what is required to run UUPC over a SLIP connection? I have heard people mention using 't' and 'e' protocols to do this. Also, is it faster? John -- Mome Raths BBS General Pix, Adult Pix, Messages, (513)523-7887 DOS, Windows and OS/2 programs, Oxford, Ohio 12 Step echos and much more ------------------------------ Date: Fri, 24 Feb 1995 08:15:26 -0500 From: uupcinfo@kew.com Subject: SLIP & UUPC To: UUPC/Extended mailing list On Thu, 23 Feb 95 20:54:06 -0500, sysop@mome-raths.iac.net wrote: > Can anyone tell me what is required to run UUPC over a SLIP connection? > I have heard people mention using 't' and 'e' protocols to do this. > Also, is it faster? You're adding at least small addressing overhead, and your data is flowing through additional hosts. To use it, get a SL/IP or PPP connection working on NT, Windows 3.1 (with a Winsock DLL) or OS/2, including Warp's Internet Access Kit or the full IBM TCP/IP for OS/2 2.0. Then use the tcp/ip modem file with suite=tcpip, and replace the phone number with the host name to contact. You can also change the protocol to "etvg". -ahd- -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 To sign off from uupc-info, send the command "signoff uupc-info" in the body of a message to listserv@kew.com. DO NOT send this request to the list itself! For human assistance with the list itself, send mail to snuffles@kew.com. "That's not a bug, it's a feature!" ------------------------------ Date: Fri, 24 Feb 1995 06:49:02 -0800 From: coffler@jeck.wa.com Subject: SLIP & UUPC To: UUPC/Extended mailing list Hi, > Can anyone tell me what is required to run UUPC over a SLIP connection? > I have heard people mention using 't' and 'e' protocols to do this. > Also, is it faster? Yes, UUCP over TCP/IP uses the 't' or 'e' protocol. Is it faster? Faster than what? It's faster than NNTP, but then NNTP is a very request-response oriented protocol, where UUCP just blasts all the data in one direction. It's probably slower than the 'g' protocol (I'd guess) _IF_ you are using a modem optimized for the 'g' protocol (Telebit Worldblazer). I suspect that the speed difference is negligible in other cases, but Drew can say for sure. It's WAY faster for me, but then my Internet connection is 56kb - the pipe is much larger for an Internet connection than for a modem connection. -- Jeff -- ------------------------------ Date: Fri, 24 Feb 1995 08:28:19 -0800 From: dmwatt@smersh.watt.com Subject: SLIP & UUPC To: UUPC/Extended mailing list To run UUPC over SLIP or PPP, you need a SLIP or PPP stack that supports the Winsock API on Windows or Windows NT, or the IBM TCP/IP API on OS/2. Is it faster? Depends on what protocol you're using for normal dial-up. The 't' and 'e' protocols assume that the network link layer keeps the connection reliable, so they have large packet sizes and no error checking. You will have the overhead of the link layer to contend with. I use 't' over Windows NT's Remote Access Service myself, because I receive my mail from a machine whose phone is a long-distance call from me. (My Internet service provider is a local call, so I save money -- I make the local call, then connect to the remote site over UUCP/'t' protocol.) Overall, dialup network performance is slightly slower than the direct dial, because we've both got relatively slow links to the Internet. On the other hand, if you've got a good, solid network link, the performance gains can be dramatic. One friend routinely reports transfer rates of over 5KB/sec. when receiving news using UUPC/extended .... over his frame relay link! - Dave Watt -- Dave Watt (N1HMB) Home: 510-352-6799 dmwatt@smersh.watt.com San Leandro, California [A computer is] like an old testament god, with lots of rules and no mercy. - Joseph Campbell ------------------------------ Date: Thu, 23 Feb 1995 07:04:57 -0500 From: uupcinfo@kew.com Subject: that digest which just went out To: UUPC/Extended mailing list Pick one. The digest which got remailed to the normal list was: A) An example of the digest version. Note that I do purge the misguided signoff attempts and leave everything else alone. (The missing real names are a bug in VMS, which the author has promised to fix). B) A mistake which wasn't my fault (it was posted from San Franciso) C) Won't happen again, even if the postmaster doesn't fix his software, because I modified the listserv to kill anything with the digest Keywords: line. D) All of the above. The correct answer is D. :-) -ahd- -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 To sign off from uupc-info, send the command "signoff uupc-info" in the body of a message to listserv@kew.com. DO NOT send this request to the list itself! For human assistance with the list itself, send mail to snuffles@kew.com. WNTC radio - Why Not Try Clyde? ------------------------------ Date: Thu, 23 Feb 1995 07:18:24 -0500 From: Help@kew.com Subject: two more 1.12M questions To: UUPC/Extended mailing list On Wed, 22 Feb 1995 21:05:07 -0500, "Michael D. Lawler" wrote: > Am I supposed to move the seqf file to my spool directory and rename it to > seqf.dat? Just delete the old one ... after you have moved off 1.12k or below for good. The file format has changed, so let the sequence numbers start over. > Also I noticed that the seqf.dat file doesn't appear to increment > properly for example before I sent my first message to you it was 2619 and > after it was 3619 when I think that it should have been 2620. You're incorrect. As of release 1.12m the sequence file is now written in the native binary format, which is not left to right. Send a couple of pieces of mail and then run UUSTAT -s all, which will show the correct order. > Also for the in memory option is the option imfile or imfiles? Try both. (imfile is the correct one). -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 "A hobbit will get you through times of no bagels better than bagels will get you through times of no hobbit." - The Grey-eyed Elf ------------------------------ Date: Wed, 22 Feb 1995 11:46:10 -0500 From: ahd@craft.camp.clarkson.edu Subject: uupc/extended 1.12m To: UUPC/Extended mailing list I have decided to ship 1.12m as a test only release -- it's on ftp.clarkson.edu in pub/betatest. PLEASE browse the README.NOW file before downloading it. It does NOT include updated docs. This release is NOT available on kewgate and will not be made on available on there -- this is mostly to test the new news support, and most people don't need it. I'm going to work on the docs while testing proceeds and hope to cough up those docs and and required fixes in the next few weeks. -ahd- ------------------------------ End of UUPC-Info-Request Digest ******************************