Date: Tue, 16 Jan 96 09:06:11 PST From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1996 #2 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Tue, 16 Jan 96 Volume 1996: Issue 2 Today's Topics: Asking for uupc mailfiles bug in rmail of 1.12q - general protection fault Bug in uux (at least on OS/2) error with mailchek Has anybody succeeded in transferring large files to a Taylor? (2 msgs) Message box from uucico NEWSRUN bug 1.12o Problem solved (was: Re: Has anybody succeeded in transferring large f (3 msgs) Problems with DOS UUCICO version 'p' (2 msgs) Problems with uucico version 'p' Problem with UUCICO ? Question re subdomain routing 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. Note: Questions on UUPC/extended itself which are not of general interest should be sent to help@kew.com, not to the mailing list. Nor questions should be posted on Usenet, we don't read it. (Much.) ---------------------------------------------------------------------- Date: 09 Jan 1996 00:00:00 +0000 From: hajo@quijote.in-berlin.de Subject: Asking for uupc mailfiles To: UUPC/Extended mailing list Hi, the programmer of an OS/2 SMTP/POP mail client wants to support UUPC. Please send me some mailfiles, if you have any without private mail. I'm running some beta add-on here, and therefore don't have the typical mailfiles, as written by UUPC. hajo -- ----[Hans-Joachim Zierke ]---------------------------------------------- [Rathenower Straße 23 ] [D-10559 Berlin-Moabit] hajo@quijote.in-berlin.de [ +49-30 / 394 84 45] ----[Fax:(0)30 / 394 84 47]---------------------------------------------- ------------------------------ Date: Mon, 15 Jan 1996 14:24:26 -0500 From: XHelp@kew.com Subject: bug in rmail of 1.12q - general protection fault To: UUPC/Extended mailing list On Sun, 24 Dec 1995 00:31:29 +0100, "Carsten Leonhardt" wrote: > I just discovered another bug in UUPC/extended 1.12q. Only one? :-) > It occurs if you do the following: > > [leo ~]rmail get < t > rmail: UUPC/extended 1.12q (OS/2 32 bit mode, 30Nov95 08:05) [debug enabled] > General Protection Fault exception occurred at EIP = 1745A3BF on thread 0001. > Exception occurred in C Library routine called from EIP = 0002188B. > Register Dump at point of exception: > EAX = 00000000 EBX = 00000000 ECX = FFFFFFFF EDX = 000318C6 > EBP = 000837CC EDI = 00000000 ESI = 00000000 ESP = 000837C8 > ÿCS = 005B CSLIM = 1BFFFFFF DS = 0053 DSLIM = 1BFFFFFF > ÿES = 0053 ESLIM = 1BFFFFFF FS = 150B FSLIM = 00000030 > ÿGS = 0000 GSLIM = 00000000 SS = 0053 SSLIM = 1BFFFFFF > Process terminating. > [leo ~] > > With file "t" containing the following lines (without ">"): > > >From leo sun Dec 10 12:57:53 1995 > >From: leo@arioch.tng.oche.de > >To: help@kew.com > >Subject: bug Corrected in 1.12r. Previous to this, it needed a remote name either before the user id terminating the line. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 I have not lost my mind; it's backed up on tape on somewhere. ------------------------------ Date: Mon, 15 Jan 1996 18:24:14 -0500 From: Software@kew.com Subject: Bug in uux (at least on OS/2) To: UUPC/Extended mailing list This change has been applied for all environments for 1.12r. It turns out rnews.C and newsrun.C pretty much already do it this way. On Mon, 4 Dec 1995 10:05:59 +0100 (MEZ), eurjof@eur.sas.com wrote: > I found the code in function CopyData() of uux.c did a bad job on OS/2 > switching stdin to binary mode. This caused all these 'batched: skipped > xxx bytes' messages as well as some corrupted compressed files being set > to the remote side. The following patch is needed to fix this problem. > > The latest patch for the IBM CSet++ (ctc0011.zip) fixes the problems of > IBM CSet generating bogus command line arguments. However, sendbats.exe > still has problems invoking compress.exe more than one. While debugging > this, i found that the second time compress.exe is called without stdin > opened. In this case, at least my version of compress just complained > about an invalid file handle and did nothing (gzip seems to be more > robust against this kind of problems). > > Cheers, > Jochen > > *** uux.c1 Sun Dec 03 20:29:30 1995 > --- uux.c Sun Dec 03 20:41:08 1995 > *************** > *** 363,370 **** > > if (input == NULL) > { > datain = stdin; > ! setmode(fileno(datain), O_BINARY); /* Don't die on control-Z, etc */ > } > else > datain = FOPEN(input, "r", IMAGE_MODE); > --- 363,374 ---- > > if (input == NULL) > { > + /* This does NOT work ! - at least on OS/2 > datain = stdin; > ! setmode(fileno(datain), O_BINARY); > ! */ > ! setmode(fileno(stdin), O_BINARY); > ! datain = fdopen(fileno(stdin),"rb"); /* Don't die on control-Z, etc */ > } > else > datain = FOPEN(input, "r", IMAGE_MODE); > *************** > *** 408,414 **** > status = KWFalse; > } > > ! if (input != NULL) > fclose(datain); > > fclose(dataout); > --- 412,418 ---- > status = KWFalse; > } > > ! /* if (input != NULL) */ > fclose(datain); > > fclose(dataout); > -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 Remote Spooling Communications Subsystem-- Only a programmer could like that name. ------------------------------ Date: Wed, 3 Jan 96 19:05:23 +0000 From: kapeka@wild-ki.netzservice.de Subject: error with mailchek To: UUPC/Extended mailing list uupcinfo@kew.com schrieb: > > On Tue, 26 Dec 95 22:28:00 +0100, peter@pgeck.sub.org wrote: > > I am getting errors with some of the cmd-files which come with > > UUPC (I forgot to mention in my previous mail that I am using the > > OS/2 32bit version). One example with mailchek: > > > > F:\uupc>mailchek > > 25 +++ initcode = VInit(); > > REX0043: Error 43 running F:\uupc\bin\mailchek.cmd, line 25: > > Routine not found > > > > Obviously something is missing but I don't know what. I have rexx > > installed and there is some vrobj.dll which should have to do > > something with visual rexx (?) although I can't see what is > > 'visual' with something like mailchek... > > MailChek puts up a small window like Xbiff to show you if you have > mail. Hence the requirement for Visual Rexx, which actually manages the > Window. Peter needs Vrexx (sp?) from the IBM EWS Program. The error occurs cause the script can't find the vrexx extension. Please note, this 'visual' environment has nothing to do with VxRexx, so VrObj.dll is not enough. regards kp -- K.P.Kirchdoerfer Voice: +49 431 15479 Kronshagener Weg 65 E-Mail: kapeka@wild-ki.netzservice.de 24116 Kiel Suicide is painless ------------------------------ Date: 04 Jan 1996 00:00:00 +0000 From: hajo@quijote.in-berlin.de Subject: Has anybody succeeded in transferring large files to a Taylor? To: UUPC/Extended mailing list Drew, Du schriebst am 03.01.96: > Define 'big'. I did just run a new comparison test some minutes ago: Sent with my DOS site: + 02:52:30 sending SPOOL\D-2A1A.OUT as D.quijoteC2A1A * 02:53:45 sent 145430 bytes, 1913 cps, 0 errors + 02:53:45 sending SPOOL\X-2A1B.OUT as X.quijoteC2A1B * 02:53:46 sent 58 bytes, 58 cps, 0 errors This was sent with uucp-g, 1024, 7, variablepacket The same file sent with UUPC, to the same remote site, using the same DTE speed and the same modem parameters, with uucp-v, 1024, 7, variablepacket will FAIL for too many protocol errors. > > With uucp-v 1024, the connection will be killed by the Taylor for too > > many protocol errors. It looks as if both sides don't agree about CRC > > computation. > > The computation would be the same for all links. It _looks_ like this for my uneducated eyes. I attach the log of the other site below. The modem-to-modem connection is error-free. Connections without MNP or LAPM are not allowed by the modem settings, and I have checked this. DTE speed is 38400, slow for my 16550. And if there is a DTE problem, it should happen when receiving, not sending. Crosspoint transfers with 0 errors out of the DOS box with 38400. More DTE errors for OS/2 software than for a DOS VDM at the same DTE speed? Can't believe that. Lost characters at remote are ruled out, since both tests were run under the same conditions, and I wouldn't get "0 errors" for my other uucico. Maybe I have overlooked something, but until now, I can't believe into anything else than a software error, either by the Taylor or by UUPC. > > With uucp-g, UUPC will happily receive 1024, but send 64 only. This nails > > the connection to 1000 cps max. > > One end needs to be reconfigured to know you can send > packets. Be sure to have GWindowSize=512. That window looks BIG. Sure you mean gPacketsize=1024. I did that. If I don't do this, both sides will send 64. If I reconfigure to 1024, the Taylor sends 1024 as expected, the UUPC 64. Since we can use v, this problem _should_ be academic, though. > > Since uucp-v is just an uucp-g with less restrictions by default, I've > > done a comparison check with my DOS site. In a DOS VDM, I can > > uucp-g-transfer with both 1024 and 4096 blocksize and variable packetsize > > with 0 errors, using Crosspoint instead of UUPC. > > This is to yourself? No. Running the DOS Crosspoint uucico to the Unix site. As far as I know, my DOS software can't connect via named pipe, therefore local checks are difficult. If my other uucico would have revealed the same problem at big blocksizes, connected to the Unix system, I wouldn't have bothered you, but have asked my feed to write to Ian Taylor instead. ;-) > > Therefore the question: Was anybody able to send a really large file (1 > > meg or more) to a Taylor uucico using 1024 blocksize or 512 at least? > > My Taylor UUCP based feed, which includes news, has very few errors, but > they may still be back on 1.04. The Taylor _feeds_ me without problems at v,1024,variable. A log looks like this, heavily edited: <...> uucico hanta - (1995-12-10 05:17:44.29 28834) Handshake successful (protocol 'v' sending packet/window 1024/7 receiving 1024/7) <...> uucico hanta hajo (1995-12-10 05:18:43.34 28834) DEBUG: fgprocess_data: Got packet 5 uucico hanta hajo (1995-12-10 05:18:43.35 28834) DEBUG: fgsend_control: Sending control RR 5 uucico hanta hajo (1995-12-10 05:18:43.35 28834) DEBUG: fgwait_for_packet: Need 1019 bytes uucico hanta hajo (1995-12-10 05:18:43.85 28834) DEBUG: fgprocess_data: Bad checksum: header 0xca2a, data 0xe5b9 uucico hanta hajo (1995-12-10 05:18:43.86 28834) DEBUG: fgsend_control: Sending control RJ 5 uucico hanta hajo (1995-12-10 05:18:43.86 28834) DEBUG: fgprocess_data: Bad header: K 48 TT 3 XOR byte 130 calc 179 uucico hanta hajo (1995-12-10 05:18:43.86 28834) ERROR: Too many 'v' protocol errors uucico hanta - (1995-12-10 05:18:43.86 28834) DEBUG: fgsend_control: Sending control CLOSE 0 uucico hanta - (1995-12-10 05:18:43.86 28834) DEBUG: fgsend_control: Sending control CLOSE 0 uucico hanta - (1995-12-10 05:18:43.86 28834) Protocol 'v' packets: sent 1, resent 0, received 45 uucico hanta - (1995-12-10 05:18:43.86 28834) Errors: header 78, checksum 14, order 12, remote rejects 0 uucico hanta - (1995-12-10 05:18:43.93 28834) DEBUG: fsend_uucp_cmd: Sending "OOOOOOO" uucico hanta - (1995-12-10 05:18:43.93 28834) DEBUG: fsend_uucp_cmd: Sending "OOOOOOO" uucico hanta - (1995-12-10 05:18:43.93 28834) DEBUG: zget_uucp_cmd: Got "\0200C+k\002H=4d\026D1\001\001.:\004\000" uucico hanta - (1995-12-10 05:18:43.98 28834) DEBUG: zget_uucp_cmd: Got "2V't-\023\016`^\021bxXh\033\004,0-$','\004L'=nKI\n|vZ\0115$\011c]pefmm\034 \036\002\021F|(bI\177\025l\003bP" uucico hanta - (1995-12-10 05:18:44.00 28834) DEBUG: zget_uucp_cmd: Got "R\020\\\013Fo1\036)H<\010'D\033@r\035P\006\024F4\n" <...> hajo ------------------------------ Date: Sat, 06 Jan 1996 08:08:49 -0500 From: uupcinfo@kew.com Subject: Has anybody succeeded in transferring large files to a Taylor? To: UUPC/Extended mailing list On 04 Jan 1996 00:00:00 +0000, hajo@quijote.in-berlin.de wrote: > Sent with my DOS site: > + 02:52:30 sending SPOOL\D-2A1A.OUT as D.quijoteC2A1A > * 02:53:45 sent 145430 bytes, 1913 cps, 0 errors > + 02:53:45 sending SPOOL\X-2A1B.OUT as X.quijoteC2A1B > * 02:53:46 sent 58 bytes, 58 cps, 0 errors > > This was sent with uucp-g, 1024, 7, variablepacket > > The same file sent with UUPC, to the same remote site, using the same > DTE speed and the same modem parameters, with uucp-v, 1024, 7, > variablepacket will FAIL for too many protocol errors. I actually use the default, which is 512 by 7. > > > With uucp-v 1024, the connection will be killed by the Taylor for too > > > many protocol errors. It looks as if both sides don't agree about CRC > > > computation. > > > > The computation would be the same for all links. > > It _looks_ like this for my uneducated eyes. I attach the log of the other > site below. > The modem-to-modem connection is error-free. Connections without MNP or > LAPM are not allowed by the modem settings, and I have checked this. DTE > speed is 38400, slow for my 16550. I use 57600 on both my modems, one a 28800 and the other 14400. I use the stock IBM drivers. > > > With uucp-g, UUPC will happily receive 1024, but send 64 only. This nails > > > the connection to 1000 cps max. > > > > One end needs to be reconfigured to know you can send > > packets. Be sure to have GWindowSize=512. > > That window looks BIG. Sure you mean gPacketsize=1024. Yes, whooops. > I did that. If I > don't do this, both sides will send 64. If I reconfigure to 1024, the > Taylor sends 1024 as expected, the UUPC 64. Since we can use v, this > problem _should_ be academic, though. Yes. > > This is to yourself? > > No. Running the DOS Crosspoint uucico to the Unix site. As far as I know, > my DOS software can't connect via named pipe, therefore local checks are > difficult. Okay. > If my other uucico would have revealed the same problem at big blocksizes, > connected to the Unix system, I wouldn't have bothered you, but have asked > my feed to write to Ian Taylor instead. ;-) > > > > > Therefore the question: Was anybody able to send a really large file (1 > > > meg or more) to a Taylor uucico using 1024 blocksize or 512 at least? > > > > My Taylor UUCP based feed, which includes news, has very few errors, but > > they may still be back on 1.04. > > The Taylor _feeds_ me without problems at v,1024,variable. I failed to mention the listserv outbound link runs over the same connection. Since December 4th, I've sent out 65M and only received 58M. Outbound is generally sent in 60K files, close enough to your 150K to be a reasonable comparision. Try vWindowSize=512, not 1024. I'll jack mine up to 1024 and see if anything funky happens. -- 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. "Be yourself. Especially, do not feign affection. Neither be cynical about love; for in the face of all aridity and disenchantment it is perennial as the grass. . ." - Desiderata ------------------------------ Date: 16 Jan 96 05:22:26 EST From: 100013.3330@compuserve.com Subject: Message box from uucico To: UUPC/Extended mailing list Hello, There is a little 'feature' which it would be a good idea to change in the Windows 3.1 executable of uucico. If the modem fails to initialise you get a message box on which you have to click OK. I think this is not a good thing - and errors should be reported in a log file only. The modem initialise script can fail if the modem is being reset just as a call comes in (for example just after uupoll has called the program specified with the -B option)- I saw it happen! Then the whole thing gets stuck until someone clicks on OK - not good for error recovery. What do you think? Nick Waltham ------------------------------ Date: Mon, 15 Jan 1996 17:53:28 -0500 From: Software@kew.com Subject: NEWSRUN bug 1.12o To: UUPC/Extended mailing list On Sun, 01 Oct 1995 20:49:49 -0700, "Bob Dodd" wrote: > In processing a reasonably large news feed, we've encountered problems > again and again with general protection faults when the history.dir > file exceeds 64k. > > That 64k number sounds suspiciously like a problem caused when > converting from a .com (everything in one 64k segment) to a .exe > program (multiple segments). A two-byte pointer that was valid in a com > program might require a double-word in an exe. > > > My background is 8088 assembler and BASIC, so my c is "read-only", and > marginal at best. I'll be glad to provide any information that I can to > help find the cause. I believe this will be fixed for 1.12r. I found two or three problems with file name sizes, buffer sizes and offsets in the 16 bit version. -ahd- -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 Remote Spooling Communications Subsystem-- Only a programmer could like that name. ------------------------------ Date: 07 Jan 1996 00:00:00 +0000 From: hajo@quijote.in-berlin.de Subject: Problem solved (was: Re: Has anybody succeeded in transferring large f To: UUPC/Extended mailing list Hallo Drew, Du schriebst am 06.01.96: > I use 57600 on both my modems, one a 28800 and the other 14400. I use > the stock IBM drivers. Your suggestion to use the IBM drivers works. I have first replaced my old SIO 1.26a (this gives the best DOS VDM performance) by the recent SIO 1.53. This does NOT help. Using the IBM drivers helps. This is amazing, since all my other OS/2 comm software works with SIO. While I don't know what's going on here, I have a temporary solution at least. "Temporary" until I get ISDN, since the IBM drivers support 57600 DTE, a little small for putting through 7500 cps. Changing the driver gives about 5 errors for 100 k still. Thanks to a suggestion by Michiel Voskamp (michielv@bigos.xs4all.nl), I have set my modem to &Y0 break handling. While this did not make the SIO driver work. it brings the errors down to 0 with the IBM driver. Again, I don't understand what's going on, but it works. hajo -- ----[Hans-Joachim Zierke ]---------------------------------------------- [Rathenower Straße 23 ] [D-10559 Berlin-Moabit] hajo@quijote.in-berlin.de [ +49-30 / 394 84 45] ----[Fax:(0)30 / 394 84 47]---------------------------------------------- ------------------------------ Date: Mon, 08 Jan 1996 17:21:42 -0500 From: uupcinfo@kew.com Subject: Problem solved (was: Re: Has anybody succeeded in transferring large f To: UUPC/Extended mailing list Note, BTW, the 'g/G/v' protocol module does have a bug which causes excessive lost connections if errors do a occur. I need to work on this, if I ever get the news out the door. On 07 Jan 1996 00:00:00 +0000, hajo@quijote.in-berlin.de wrote: > Your suggestion to use the IBM drivers works. I have first replaced my old > SIO 1.26a (this gives the best DOS VDM performance) by the recent SIO 1.53. > This does NOT help. Curious. One might suspect SIO is allowing a queue overrun, over driving the port (causing the modem to lose data), or some similar error, but the SIO drivers are well respected and widely used. As for the UUPC/extended use of the serial port, it's pretty boring; Dave Watt (who ported the OS/2 code to NT) and I discussed it, and we could not really thing of anything strange the code does. > Using the IBM drivers helps. This is amazing, since all my other OS/2 comm > software works with SIO. While I don't know what's going on here, I have a > temporary solution at least. "Temporary" until I get ISDN, since the IBM > drivers support 57600 DTE, a little small for putting through 7500 cps. > > > Changing the driver gives about 5 errors for 100 k still. Thanks to a > suggestion by Michiel Voskamp (michielv@bigos.xs4all.nl), I have set my > modem to &Y0 break handling. While this did not make the SIO driver > work. it brings the errors down to 0 with the IBM driver. Again, I don't > understand what's going on, but it works. This depends on what &Y0 does, in two different modem commands I just check it does two entirely different things. -- 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. "...DOS is utterly unable to handle more than 1MB of memory. Removing this limitation from DOS would result in something that just _isn't_ DOS any more--it wouldn't run existing DOS programs." - PC Magazine, Nov 23, 1993. ------------------------------ Date: Mon, 8 Jan 96 19:09:05 -0500 From: uupc@mistik.express.net Subject: Problem solved (was: Re: Has anybody succeeded in transferring large f To: UUPC/Extended mailing list ... > On 07 Jan 1996 00:00:00 +0000, hajo@quijote.in-berlin.de wrote: > > Your suggestion to use the IBM drivers works. I have first replaced my old > > SIO 1.26a (this gives the best DOS VDM performance) by the recent SIO 1.53. > > This does NOT help. > > Curious. One might suspect SIO is allowing a queue overrun, over > driving the port (causing the modem to lose data), or some similar > error, but the SIO drivers are well respected and widely used. As for I will disagree on this account. I can't use them because they break down something, something different with each version. ... > > Using the IBM drivers helps. This is amazing, since all my other OS/2 comm > > software works with SIO. While I don't know what's going on here, I have a > > temporary solution at least. "Temporary" until I get ISDN, since the IBM > > drivers support 57600 DTE, a little small for putting through 7500 cps. What are you going to use? I suppose something that has a network interface, right? > > > > > > Changing the driver gives about 5 errors for 100 k still. Thanks to a > > suggestion by Michiel Voskamp (michielv@bigos.xs4all.nl), I have set my > > modem to &Y0 break handling. While this did not make the SIO driver > > work. it brings the errors down to 0 with the IBM driver. Again, I don't > > understand what's going on, but it works. > > This depends on what &Y0 does, in two different modem commands I just > check it does two entirely different things. It has helped reducing the errors on my system to set the uucico priority to timecritical, and the delta to 3/4 of the range. ... ------------------------------ Date: 11 Jan 96 01:32:28 EST From: 100013.3330@compuserve.com Subject: Problems with DOS UUCICO version 'p' To: UUPC/Extended mailing list I am currently trying to install DOS UUPC as a server - I am using version 'p'. When I run uucico -r0 it usually reports a memory allocation failure. There are 36 entries in the systems file. Version 'j' does not report any errors. I havn't tried yet with k. The dos executable does not report this error on a 486 with 8MB of ram but does on a 386 with 4MB of ram. I wonder if it has been compiled with optimisations for 486 on? Has anyone seen this? Thanks in advance, Nicholas Waltham ------------------------------ Date: Mon, 15 Jan 1996 12:40:25 -0500 From: uupcinfo@kew.com Subject: Problems with DOS UUCICO version 'p' To: UUPC/Extended mailing list On 11 Jan 96 01:32:28 EST, 100013.3330@compuserve.com wrote: > I am currently trying to install DOS UUPC as a server - I am using > version 'p'. When I run uucico -r0 it usually reports a memory > allocation failure. Where? There are perhaps over 100 places that the program allocates memory during different stages, knowing the failure area is very important. > There are 36 entries in the systems file. Version > 'j' does not report any errors. I havn't tried yet with k. The dos > executable does not report this error on a 486 with 8MB of ram but does > on a 386 with 4MB of ram. Since UUPC/extended does not use extended memory, overall memory does not matter but rather memory free under 640K and more importantly, the amount of near memory (which is limited by the processor to 64K). Have you run MEMMAKER? > I wonder if it has been compiled with optimisations for 486 on? We switched compilers (BC to MS) between the two versions; both were set to use standard optimizations, but are not optimized for a particular processor. -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. "I saw a werewolf drinking a Pina Colada at Trader Vic's . . ." ------------------------------ Date: 16 Jan 96 00:00:19 EST From: 100013.3330@compuserve.com Subject: Problems with uucico version 'p' To: UUPC/Extended mailing list Hi Drew, Thanks for your speedy reply: >> I am currently trying to install DOS UUPC as a server - I am using >> version 'p'. When I run uucico -r0 it usually reports a memory >> allocation failure. > >Where? There are perhaps over 100 places that the program allocates >memory during different stages, knowing the failure area is very >important. Here is the relevant chunk of the log file. If I run at a higher level of debugging it seems its after the modem cfg file is loaded I don' think it stops in exactly the same place every time - I think I have seen it stop at line eight hundred and something but I cannot be sure. 01/16-10:40 UUCICO: UUPC/extended 1.12p (Nov 8 1995 07:29:54) 01/16-10:40 Storage allocation failure; possible cause: memory shortage. 01/16-10:40 UUCICO aborting at line 740 in file lib\configur.c >Since UUPC/extended does not use extended memory, overall memory does >not matter but rather memory free under 640K and more importantly, the >amount of near memory (which is limited by the processor to 64K). Have >you run MEMMAKER? Yes - I think my CFG and Autoexec are optimised and minimal - I have 609k of DOS memory. I don't understand your point about near memory - what memory model are you using - surely not tiny? medium and large limit you to 64k per array (can't remember about small - its a little while since I did C++ programming) >> I wonder if it has been compiled with optimisations for 486 on? > >We switched compilers (BC to MS) between the two versions; both were set >to use standard optimizations, but are not optimized for a particular >processor. Maybe there is a difference in the granularity of the heap between these two compilers or the MS library is just fatter or something? I haven't used MS C only BC. Thank you again for your help, Nick Waltham ------------------------------ Date: Mon, 15 Jan 1996 14:30:59 -0500 From: XHelp@kew.com Subject: Problem with UUCICO ? To: UUPC/Extended mailing list On Tue, 26 Dec 1995 17:32:06, "William Joye" wrote: > We have noted a problem with UUCICO when the mail server is configured to > reject all the files send from a local system. The local UUCICO delete the > command files and leave the data files alone in the 'D' directory. > > We think that UUCICO must delete the data files too. Is it a real bug ? Yes, it should delete the data files. This will be corrected in 1.12r. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 I have not lost my mind; it's backed up on tape on somewhere. ------------------------------ Date: Sun, 7 Jan 1996 15:52:11 -0500 (EST) From: cmaurand@biddeford.com Subject: Question re subdomain routing To: UUPC/Extended mailing list On Thu, 28 Dec 1995 colmarr@conicit.ve wrote: > Greetings! > > I am glad to report that after many trials we have finally gotten UUPC to work > with our provider over tcp/ip and we are sending and receiving mail succesfuly > several times daily. If others are having trouble setting it, perhaps I can help > with examples of how we did it here. It works really well. > > Now, we are setting up a uucp neighbor who will dial into our system and get > mail from us. The mail is addressed like this for users of his system: > > username@neighborsystem.oursystem.ourprovider.net > > but when we get the mail from our provider, the control file makes no mention of > the neighborsystem subdomain. There, the C line reads simply > > C rmail username > > which causes the mail to be delivered wrong (to postmaster here unless we set up > each of the neighboirsystem's users with a separate entry in our ALIASES file, a > workaround which is cumbersome and surely not necessary). > > What I need from our provider instead is a control file that makes a mention of > the subdomain, if the mail came not to our central system but to a subdomain > originally. Like this: > > C rmail neighborsystem!username > > What does my provider have to do so that his system is aware of this and > generates the control files to me correctly? > > PLEASE HELP> I am sure it is some quick entry, but reading the manual has not > made it clear to me (yet) where we do it or even how... > > Best regards, and a happy new years, > --colmarr@dino.conicit.ve > > I might think about getting your provider to modify his/her sendmail to refelct that all mail for your neighbors system to be deliverred to your system. (If you both have different domain names) Then use the hostpaths system to specify that all mail to that system be delivered to that host. I made this work, as soon as I get access to that drive again, I will send you copies of my uupc.rc and hostpath file. ------------------------------ End of UUPC-Info-Request Digest ******************************