Date: Sat, 9 Dec 95 17:06:09 PST From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1995 #50 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Sat, 9 Dec 95 Volume 1995: Issue 50 Today's Topics: Error in Newsrun under Win95 Good news (sort of) (3 msgs) hayes Optima 28.8 NEWSRUN bug 1.12p UUPC/extended UUCICO under Windows & TCP/IP uupc with windows tcpip 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: Sat, 09 Dec 1995 08:26:11 -0500 From: uupcinfo@kew.com Subject: Error in Newsrun under Win95 To: UUPC/Extended mailing list On Fri, 08 Dec 1995 22:32:14 +0100, "Siegfried Schlosser" wrote: > I'm using uupc now for three days. I use the Windows NT binaries > 'cause I run Win95. > > From time to time I get an Error and Newsrun is stopped. Win95 > shows the following Message : > ----- > NEWSRUN verursachte einen Fehler durch eine ungültige Seite > in Modul NEWSRUN.EXE bei 0137:0040274e. > Register: > EAX=00000399 CS=0137 EIP=0040274e EFLGS=00010212 > EBX=00000000 SS=013f ESP=0065ee54 EBP=0000004a > ECX=000000e6 DS=013f ESI=202c313a FS=2417 > EDX=0065ee1c ES=013f EDI=006b2b50 GS=0000 > Bytes bei CS:EIP: > f3 a5 8b c8 83 e1 03 f3 a4 85 ed 0f 85 98 00 00 > Stapelwerte: > 0065f4c4 00000000 00000000 0041b548 006b2b50 00000000 > 00000399 00000001 0067f264 656e7773 6f6a2e74 6a007362 > 0073626f 6e652e00 00797274 6f6a2e6e > ------ > Can someone please give me a clue whats going on? I suspect the problem is it's looking for a news group you don't have in your active file. This is a bug, as soon as i get a list to sort properly, I'll be putting out a fix. -- 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. "She was married when we first met | Both agreeing it was best Soon to be divorced | She turned around to look at me I helped her out of a jam I guess | As I was walking away But I used a little too much force | I heard her say over my shoulder We drove that car as far as we | We'll meet again some day on the could | avenue Abandoned it out west | Tangled up in blue . . ." Split up on a dark sad night | - Bob Dylan ------------------------------ Date: Fri, 08 Dec 1995 19:22:44 -0500 From: uupcinfo@kew.com Subject: Good news (sort of) To: UUPC/Extended mailing list On Fri, 8 Dec 95 6:14:27 -0500, uupc@mistik.express.net wrote: > > On Mon, 4 Dec 1995 07:42:45 -0400 (AST), colmarr@conicit.ve wrote: > > > I am still boxing with the (so far unsuccesful) connection to my uucp provider > > > over tcp/ip, but I recently received some GOOD NEWS from Dirk in Germany. He > > > says that he got *his* uucp over tcp/ip _working_ and on the first try, even. > > > So there is still hope for us here, too... > > > > > > I'd like to know from you, him and any others what a succesful configuration > > > should look like. I.e., what would be the recommended OS and what PPP package > > > works, also what uucp provider to use and/or how the polled system should be set > > > up so this works smooth. > > > > > I know this request sounds like a mouthful, but if someone has it > > > working, or if > > > > Please cease and desist your current thread of mail to the list. While > > I fully support UUCICO over a working TCP/IP connection (see following > > paragraph), I have attempted to explain to you a number of times you > > have yet to demonstrate working TCP/IP connection, and rather than doing > > so you connect to pester me personally and the list in general fishing > > for the reason your particular site doesn't work. These repeated > > queries are taking of a considerable amount of my time, so again: Please > > Cease and Desist. > > errr, btw, at the risk of getting kicked out again....This isn't exactly > customer frendly... You're correct, it's not (customer friendly). It's not exactly off the mark to make that comment, so I'm not going to nuke you. :-) However, I am not in position to support a user in a foreign country who knows nothing of TCP/IP attempting to connect to a service provider (you) who would rather bitch about the service provided then submit specific bug reports which I can work on. At this time, I believe I only have one active problem on file from you, a problem with the ordering of fields in the SYS file. (As for the kicked out, I never actually let you back in -- looks like the listserv configuration is screwed up. I'll leave it as it is for now, which effectively leaves you on probation. I'd suggest you leave off the attacks and the advertising.) > > As a point of fact, it works fine for me connecting either two > > UUPC/extended systems (normally, I use a loopback) or to a real Internet > > host (either of my Internet feeds) running Taylor UUCP. I connect using > > 'e' protocol using Warp Connect and the IBM Internet connection to get > > out. > > > > My systems file looks like this: > > > > ci-feed Any TCPIP 57600 feed.ci.net e gin: Ukendra\rpassword > > > > While I typed this, my connection to the above system sent 70 files > > > > I have given you your next instructions on how to solve your problems, > > you have yet to report to me that you followed them, nor has Mustafa > > reported to me a specific problem with UUPC/extended for me to fix. > > ;) Perharps it is because I have given up on my expectations of a 'fix'. > I asked you specifically for the visualage make situation, you still > have not provided instructions on what sort of output you want and how > to obtain it. Your latest response on the Visual Age Makefile problem is less than 24 hours old. I first saw it about five minutes ago, and I'm considering my options. I'll reply to it separately. As reasonable readers of this list will note, my normal response time to mail varies between a few hours and a few days. Since your mail was delivered to this system last night the mail is less than a day old, and thus you should NOT be complaining. > I am trying to compile it myself because I want to fix it. I don't have > confidence that you will fix the bugs I report. You have not > demonstrated such so far. Instead, I got lipservice for next release > which didn't come around while I was on the list. Then I didn't get an > announcement of the p version either....Still no printed manuals, etc > etc... You were not notified of 1.12p because you specifically said you would NOT be upgrading. You were also informed if you are unhappy with our service you could receive a full refund of the money submitted. You have not requested a refund in the months since this offer was first made. Please inform help@kew.com if you wish to resume receiving upgrade notices. > Here is a bunch of problems other than those I reported. uucico does > not run in the server mode over tcp properly. It seems that the socket > configuration is wrong. As a result, you ar getting an error code that > can mean both a broken connection or just empty buffer at the time you > poll. You are interpreting it as a broken connection. You don't specify the environment. I'll presume OS/2. I just tested this under OS/2 Warp Connect and it worked fine; the log follows. It also works under INETD. In answer to your other question, I have not run TCP/IP UUCICO from Windows 3.1 in some time. Thus, I have no information on it. Dave Watt is routinely using it under Windows NT, so any problems would have to be with the Windwos 3.1 specific code. > Therefore, the > server will quit the connection. Now, I need instructions on how to > compile this beast since the makefile is no good. (I have to check yet > on the programmers toolkit installation issue) Send me at software@kew.com a log uucico -x 4 -r 0 showing this, please. > > Until do you follow my instructions and perform the test (telneting to > > the remote port), please DO NOT post further to UUPC-Info _or_ send me > > mail. > > Telnetting to port 540 is a bad idea. You know why? Because uucico > will get confused and will report that the address is in use and loop > until something or other times out. And, during the wntire time, it > will beep the hell out of the neighbourhood. So I told him not to > telnet and I am glad he followed my instructions. No, it's not a bad idea, I've had to debug both UNIX and UUPC/extended TCP/IP UUCPD servers this way. The first thing it vefifies is the user can connect to the remote system, and the that the server is up and running on port 540. Given the particular errors of the user saw, this not an unreasonable check. > Another bad thing about telnetting is, that telnet will send some > negotiation stuff which will ruin the username. Therefore, it will give > a bad login. If the server system is UUPC/extended, the login will be reprompted for. Thus, this is not a major issue. > The '\' option seems not to work. Note that due to system > reasons, uucico is invoked directly from a script, not from uupoll or like. My test below was invoked directly from the OS/2 command line. > Furthermore, telnet sends a crlf which results in an empty (bad) > password for the account. It is useless. No, use a Cntrl-J for the password. This is a hack, of course. The important issue is if the user can get to the password prompt, the tcp/ip software works and the user can return to UUCICO and it's script logging to perform the remaining debugging. > However, the test of a properly functioning telnet package on the > windows machine is something that needs to be tested first. Somehow, > there seems to be no software that works....Is that right? I don't understand what your last question is asking. UUCICO is known to work with TCP/IP under OS/2 and Windows NT, and is believed to work under Windows. Let me correct that ... I KNOW it works under Windows 3.1, I just tested it with a loopback connection to my own host; the log looks pretty much like the OS/2 run. Here's the log of UUCICO working from the command line, the command line was: uucico -r 0 -x 4 -m tcpip ... and the server side of the OS/2 log is: 12/08-18:56 uucico: UUPC/extended 1.12q (Nov 30 1995 08:05:05) (2) Warning ... invalid PERMISSIONS file entry ~/: (2) Run time library error 23 in E:\SRC\UUPC\LIB\SECURITY.C at line 759 ... (0) e:/public/altamira: The file or directory specified cannot be found. . . (several of these deleted) . (2) Run time library error 23 in E:\SRC\UUPC\LIB\SECURITY.C at line 759 ... (0) e:/public/kewgate: The file or directory specified cannot be found. (3) getmodem: loading modem configuration file E:/UUPC/tcpip.MDM (4) chooseCommunications: Chose suite tcp/ip (4) S state = B (4) S state = H (2) suspend_ready: Port in use (2) OS/2 API error 6 in E:\SRC\UUPC\UUCICO\SUSPEND2.C at line 774 ... (0) DosPostEventSem: Incorrect internal file identifier. (1) Monitoring port tcptty device tcpip for 546 minutes until user hits Ctrl-Break (4) S state = I (4) ==> Kendra Electronic Wonderworks (4) ==> (4) ==> Unauthorized Access Prohibited by Law (4) ==> (4) ==> The anonymous kermit server is no longer available, use anonymous UUCP (4) ==> (userid nuucp, pswd nuucp) instead. Download ~nuucp/index for you-know- (4) ==> what. Files can also be ordered via e-mail from the listserv@kew.com; (4) ==> send it an INDEX command for details. (4) ==> OS/2(R) 2.30 with UUPC/extended 1.12q (pandora.kew.com) (tcptty) (4) ==> login: (4) <== Uffactory (4) ==> Password: (4) <== password (4) ==> Welcome to pandora.kew.com; login complete at Fri, 08 Dec 1995 18:56:58 -0500 (0) login: login user Uffactory (The Fantasy Factory) at Fri Dec 8 18:56:58 1995 (4) S state = A (4) S state = K (4) ==> ^pShere=pandora (4) <== ^pSffactory (2) 1st msg from remote = Sffactory (2) OS/2 API error 123 in E:\SRC\UUPC\LIB\IMPORT.C at line 812 ... (0) E:/UUPC/spool/locks.lck/.DUMB.TEST.NAME: SYS0123: A file name or volume label contains an incorrect character. (4) advancedFS: E:/UUPC/spool/locks.lck/ffactory.LCK resides on file system supporting only 8.3 names (4) ==> ^pROK (4) ==> ^pPgGfvet (4) <== ^pUe (3) setproto: wanted 'e', have 'g' (3) setproto: wanted 'e', have 'G' (3) setproto: wanted 'e', have 'f' (3) setproto: wanted 'e', have 'v' (3) setproto: wanted 'e', have 'e' (0) pandora called by ffactory: network link, e protocol, z grade (4) S state = M (3) ImportPath: Mapped E:/UUPC/spool/locks.lck/*status.LCS to E:/UUPC/spool/locks.lck/2status.LCS (4) process: Machine state is = m (4) process: Machine state is = l (4) process: Machine state is = n (4) <== H (2) <<< H (4) process: Machine state is = s (2) scandir: couldn't opendir() E:/UUPC/spool/ffactory/C (2) >>> HY (4) <== HY (2) <<< HY (4) process: Machine state is = v (4) S state = N (4) ==> ^pOOOOOO (4) <== ^pOOOOOO (4) ==> ^pOOOOOO (0) 0 files sent, 0 files received, 3 bytes sent, 5 bytes received (0) 3 packets transferred, 0 errors, connection time 0:03, 2 bytes/second (4) S state = P (4) S state = Q (3) ImportPath: Mapped E:/UUPC/spool/locks.lck/*status.LCS to E:/UUPC/spool/locks.lck/2status.LCS -- 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. The objective of all dedicated employees should be to thoroughly analyze all situations, anticipate all problems prior to their occurrence, have answers for for these problems, and move swiftly to solve these problems when called upon. However, when you are up to your ass in alligators it is difficult to remind yourself your initial objective was to drain the swamp. ------------------------------ Date: Fri, 8 Dec 95 20:55:44 -0500 From: uupc@mistik.express.net Subject: Good news (sort of) To: UUPC/Extended mailing list > > On Fri, 8 Dec 95 6:14:27 -0500, uupc@mistik.express.net wrote: > > > On Mon, 4 Dec 1995 07:42:45 -0400 (AST), colmarr@conicit.ve wrote: > > > > I am still boxing with the (so far unsuccesful) connection to my uucp provider > > > > over tcp/ip, but I recently received some GOOD NEWS from Dirk in Germany. He > > > > says that he got *his* uucp over tcp/ip _working_ and on the first try, even. > > > > So there is still hope for us here, too... > > > > > > > > I'd like to know from you, him and any others what a succesful configuration > > > > should look like. I.e., what would be the recommended OS and what PPP package > > > > works, also what uucp provider to use and/or how the polled system should be set > > > > up so this works smooth. > > > > > > > I know this request sounds like a mouthful, but if someone has it > > > > working, or if > > > > > > Please cease and desist your current thread of mail to the list. While > > > I fully support UUCICO over a working TCP/IP connection (see following > > > paragraph), I have attempted to explain to you a number of times you > > > have yet to demonstrate working TCP/IP connection, and rather than doing > > > so you connect to pester me personally and the list in general fishing > > > for the reason your particular site doesn't work. These repeated > > > queries are taking of a considerable amount of my time, so again: Please > > > Cease and Desist. > > > > errr, btw, at the risk of getting kicked out again....This isn't exactly > > customer frendly... > > You're correct, it's not (customer friendly). It's not exactly off the > mark to make that comment, so I'm not going to nuke you. :-) > > However, I am not in position to support a user in a foreign country who > knows nothing of TCP/IP attempting to connect to a service provider > (you) who would rather bitch about the service provided then submit > specific bug reports which I can work on. Wrong. I am not providing the ppp access to the internet for him. He connects locally to his provider there with ppp. He gets his mail from me with uucp over tcp (when it works). Currently, I am delivering his mail by other means (forwarding program, scripts etc) for his entire subdomains under express.net. However, it is rather painful for him to process the mail on that end since he cannot use uupc for the job. Btw, has anyone used Internet for Windows from IBM yet? > At this time, I believe I only have one active problem on file from you, > a problem with the ordering of fields in the SYS file. > > (As for the kicked out, I never actually let you back in -- looks like > the listserv configuration is screwed up. I'll leave it as it is for > now, which effectively leaves you on probation. I'd suggest you leave > off the attacks and the advertising.) Your real reason is that you could not put up with my critic of your lack of support which is still valid. You have a choice of letting me in, and I will put my critisizm and questions on your lists, or I will go to usenet, and let the world know about it. It is a business decision for you, and you can do what you want (I would have some leverage though). > > > > As a point of fact, it works fine for me connecting either two > > > UUPC/extended systems (normally, I use a loopback) or to a real Internet > > > host (either of my Internet feeds) running Taylor UUCP. I connect using > > > 'e' protocol using Warp Connect and the IBM Internet connection to get > > > out. > > > > > > My systems file looks like this: > > > > > > ci-feed Any TCPIP 57600 feed.ci.net e gin: Ukendra\rpassword > > > > > > While I typed this, my connection to the above system sent 70 files > > > > > > I have given you your next instructions on how to solve your problems, > > > you have yet to report to me that you followed them, nor has Mustafa > > > reported to me a specific problem with UUPC/extended for me to fix. > > > > ;) Perharps it is because I have given up on my expectations of a 'fix'. > > I asked you specifically for the visualage make situation, you still > > have not provided instructions on what sort of output you want and how > > to obtain it. > > Your latest response on the Visual Age Makefile problem is less than 24 > hours old. I first saw it about five minutes ago, and I'm considering > my options. I'll reply to it separately. ok. > > As reasonable readers of this list will note, my normal response time to > mail varies between a few hours and a few days. Since your mail was > delivered to this system last night the mail is less than a day old, and > thus you should NOT be complaining. Maybe it was delayed on its way. It left here immediately...Then again, I don't know when kew.com picks up its MX forwarded mail?... > > > I am trying to compile it myself because I want to fix it. I don't have > > confidence that you will fix the bugs I report. You have not > > demonstrated such so far. Instead, I got lipservice for next release > > which didn't come around while I was on the list. Then I didn't get an > > announcement of the p version either....Still no printed manuals, etc > > etc... > > You were not notified of 1.12p because you specifically said you would > NOT be upgrading. You were also informed if you are unhappy with our Yet you did not provide a fix. However, you said I was on the announcements list.... > service you could receive a full refund of the money submitted. You > have not requested a refund in the months since this offer was first > made. Yes, I wasn't sure if I should let you off the hook :) Yet, although I have not responded, I have not received neither the notice nor the manuals.... > > Please inform help@kew.com if you wish to resume receiving upgrade > notices. Will do. > > > Here is a bunch of problems other than those I reported. uucico does > > not run in the server mode over tcp properly. It seems that the socket > > configuration is wrong. As a result, you ar getting an error code that > > can mean both a broken connection or just empty buffer at the time you > > poll. You are interpreting it as a broken connection. > > You don't specify the environment. I'll presume OS/2. I just tested > this under OS/2 Warp Connect and it worked fine; the log follows. It > also works under INETD. Well, I am using OS/2 2.1, and the TCP/IP product with winsocks addition. I will forward the next log when I get my hands on. > > In answer to your other question, I have not run TCP/IP UUCICO from > Windows 3.1 in some time. Thus, I have no information on it. Dave Watt > is routinely using it under Windows NT, so any problems would have to be > with the Windwos 3.1 specific code. Good to know. Helps debugging what is happening. > > > Therefore, the > > server will quit the connection. Now, I need instructions on how to > > compile this beast since the makefile is no good. (I have to check yet > > on the programmers toolkit installation issue) > > Send me at software@kew.com a log uucico -x 4 -r 0 showing this, please. > > > > Until do you follow my instructions and perform the test (telneting to > > > the remote port), please DO NOT post further to UUPC-Info _or_ send me > > > mail. > > > > Telnetting to port 540 is a bad idea. You know why? Because uucico > > will get confused and will report that the address is in use and loop > > until something or other times out. And, during the wntire time, it > > will beep the hell out of the neighbourhood. So I told him not to > > telnet and I am glad he followed my instructions. > > No, it's not a bad idea, I've had to debug both UNIX and UUPC/extended > TCP/IP UUCPD servers this way. The first thing it vefifies is the > user can connect to the remote system, and the that the server is up and Yes it is a bad idea, I rather have him verify his tcp connection elsewhere. I don't like my system turning into a beeping monster. Now, if uupc wasn't doing this, I could care less. > running on port 540. Given the particular errors of the user saw, this > not an unreasonable check. Not unreasonable to check if telnet to elsewhere works. However, unreasonable to tlnet to port 540 here at this stage of debugging considering what it does here. Practically, while it is looping like that, service is unavailable to other users. It is a denial of service... > > > Another bad thing about telnetting is, that telnet will send some > > negotiation stuff which will ruin the username. Therefore, it will give > > a bad login. > > If the server system is UUPC/extended, the login will be reprompted for. > Thus, this is not a major issue. Except, the user will turn around and claim that I may not have setup his account....And with the next attempt, it will fail again due to the crlf issue. > > > The '\' option seems not to work. Note that due to system > > reasons, uucico is invoked directly from a script, not from uupoll or like. > > My test below was invoked directly from the OS/2 command line. That's not how a server runs here, however, the call in the script looks like that. > > > Furthermore, telnet sends a crlf which results in an empty (bad) > > password for the account. It is useless. > > No, use a Cntrl-J for the password. This is a hack, of course. And of course, the user doesn't know that when he tries it. And looking at the log, I have no way of telling what he typed. > > The important issue is if the user can get to the password prompt, the > tcp/ip software works and the user can return to UUCICO and it's script > logging to perform the remaining debugging. We do agree that windows ppp is not working for port 540 so far. He is not getting here. He does not need to use telnet to verify that, the logs here indicate that he is not connecting, and his debug log indicated the same. I suspect the bad socket configuration being also part of this. However, the windows ppp issue has to be resolved first. > > > However, the test of a properly functioning telnet package on the > > windows machine is something that needs to be tested first. Somehow, > > there seems to be no software that works....Is that right? > > I don't understand what your last question is asking. UUCICO is known Questioning the existance of a windows ppp package that works for using programs under windows (real windows not WinOS2) using the winsock API. > to work with TCP/IP under OS/2 and Windows NT, and is believed to work > under Windows. Let me correct that ... I KNOW it works under Windows Ahaaaaaa..... > 3.1, I just tested it with a loopback connection to my own host; the log > looks pretty much like the OS/2 run. ;) WinOS2 is not Windows. It is better than that :) However, the user wants to use windows. I think it is a matter of 286/386... How did you setup the loopback? I would like to do that for testing new accounts I setup. > > Here's the log of UUCICO working from the command line, the command line > was: > > uucico -r 0 -x 4 -m tcpip > > ... and the server side of the OS/2 log is: > > 12/08-18:56 uucico: UUPC/extended 1.12q (Nov 30 1995 08:05:05) > (2) Warning ... invalid PERMISSIONS file entry ~/: > (2) Run time library error 23 in E:\SRC\UUPC\LIB\SECURITY.C at line 759 ... > (0) e:/public/altamira: The file or directory specified cannot be found. > . > . (several of these deleted) Do those lines also include error messages on OS/2 APIs? > . > (2) Run time library error 23 in E:\SRC\UUPC\LIB\SECURITY.C at line 759 ... > (0) e:/public/kewgate: The file or directory specified cannot be found. > (3) getmodem: loading modem configuration file E:/UUPC/tcpip.MDM > (4) chooseCommunications: Chose suite tcp/ip > (4) S state = B > (4) S state = H > (2) suspend_ready: Port in use > (2) OS/2 API error 6 in E:\SRC\UUPC\UUCICO\SUSPEND2.C at line 774 ... > (0) DosPostEventSem: Incorrect internal file identifier. > (1) Monitoring port tcptty device tcpip for 546 minutes until user hits Ctrl-Break > (4) S state = I > (4) ==> Kendra Electronic Wonderworks > > (4) ==> > > (4) ==> Unauthorized Access Prohibited by Law > > (4) ==> > > (4) ==> The anonymous kermit server is no longer available, use anonymous UUCP > > (4) ==> (userid nuucp, pswd nuucp) instead. Download ~nuucp/index for you-know- > > (4) ==> what. Files can also be ordered via e-mail from the listserv@kew.com; > > (4) ==> send it an INDEX command for details. > > (4) ==> > > OS/2(R) 2.30 with UUPC/extended 1.12q (pandora.kew.com) (tcptty) I have been looking for 12.q and could not find it. Where is it? > > (4) ==> > > login: > (4) <== Uffactory > (4) ==> > > Password: > (4) <== password > (4) ==> > > Welcome to pandora.kew.com; login complete at Fri, 08 Dec 1995 18:56:58 -0500 > > (0) login: login user Uffactory (The Fantasy Factory) at Fri Dec 8 18:56:58 1995 > (4) S state = A > (4) S state = K > (4) ==> ^pShere=pandora > (4) <== ^pSffactory > (2) 1st msg from remote = Sffactory > (2) OS/2 API error 123 in E:\SRC\UUPC\LIB\IMPORT.C at line 812 ... There, what are these API errors? > (0) E:/UUPC/spool/locks.lck/.DUMB.TEST.NAME: SYS0123: A file name or volume label contains an incorrect character. > (4) advancedFS: E:/UUPC/spool/locks.lck/ffactory.LCK resides on file system supporting only 8.3 names > (4) ==> ^pROK > (4) ==> ^pPgGfvet > (4) <== ^pUe > (3) setproto: wanted 'e', have 'g' > (3) setproto: wanted 'e', have 'G' > (3) setproto: wanted 'e', have 'f' > (3) setproto: wanted 'e', have 'v' > (3) setproto: wanted 'e', have 'e' > (0) pandora called by ffactory: network link, e protocol, z grade > (4) S state = M > (3) ImportPath: Mapped E:/UUPC/spool/locks.lck/*status.LCS to E:/UUPC/spool/locks.lck/2status.LCS > (4) process: Machine state is = m > (4) process: Machine state is = l > (4) process: Machine state is = n > (4) <== H > (2) <<< H > (4) process: Machine state is = s > (2) scandir: couldn't opendir() E:/UUPC/spool/ffactory/C Now, if you had actually queued something, you may have gotten the same error message I get with the broken connection. Can you run it with a mail or two queued in the spool and saee if it transfers correctly. Here, it will abort after it goes to check the incoming stream for packet acks....'t' protocol....Note the difference plase..... 't' protocol seems to work in the client mode, however, fails in the server mode due to the socket configuration error I mentioned. > (2) >>> HY > (4) <== HY > (2) <<< HY > (4) process: Machine state is = v > (4) S state = N > (4) ==> ^pOOOOOO > (4) <== ^pOOOOOO > (4) ==> ^pOOOOOO > (0) 0 files sent, 0 files received, 3 bytes sent, 5 bytes received > (0) 3 packets transferred, 0 errors, connection time 0:03, 2 bytes/second > (4) S state = P > (4) S state = Q > (3) ImportPath: Mapped E:/UUPC/spool/locks.lck/*status.LCS to E:/UUPC/spool/locks.lck/2status.LCS > -- > 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. > > The objective of all dedicated employees should be to thoroughly analyze all > situations, anticipate all problems prior to their occurrence, have answers for > for these problems, and move swiftly to solve these problems when called upon. > > However, when you are up to your ass in alligators it is difficult to remind > yourself your initial objective was to drain the swamp. ------------------------------ Date: Sat, 09 Dec 1995 13:00:16 -0500 From: docs@kew.com Subject: Good news (sort of) To: UUPC/Extended mailing list On Fri, 8 Dec 95 20:55:44 -0500, uupc@mistik.express.net wrote: > > > errr, btw, at the risk of getting kicked out again....This isn't exactly > > > customer frendly... > > > > You're correct, it's not (customer friendly). It's not exactly off the > > mark to make that comment, so I'm not going to nuke you. :-) > > > > However, I am not in position to support a user in a foreign country who > > knows nothing of TCP/IP attempting to connect to a service provider > > (you) who would rather bitch about the service provided then submit > > specific bug reports which I can work on. > > Wrong. I am not providing the ppp access to the internet for him. He > connects locally to his provider there with ppp. He gets his mail from > me with uucp over tcp (when it works). Currently, I am delivering his > mail by other means (forwarding program, scripts etc) for his entire > subdomains under express.net. However, it is rather painful for him to > process the mail on that end since he cannot use uupc for the job. You are quibbling about semantics, Drew meant you are the *UUCP* service provider. The following are true statements: 1. The user in question is located in a foreign country. 2. The user in question has no knowledge of TCP/IP. 3. The user is attempting to connect, via TCP/IP, to your system. 4. Your system does not appear to be able to reliably service this connection. 5. We are unable to help the user with #3 until #4 is resolved. 6. #1 and #2 further complicate attempts to resolve #3 and #4. Now, it seems to me that your time would be better spent in trying to resolve #4, for example by submitting detailed bug reports, than in arguing about whether you are or are not a "service provider". > Your real reason is that you could not put up with my critic of your > lack of support which is still valid. You have a choice of letting me > in, and I will put my critisizm and questions on your lists, or I will > go to usenet, and let the world know about it. It is a business > decision for you, and you can do what you want (I would have some > leverage though). My experience is that unfounded ranting on Usenet tends to be met with the contempt that it deserves, especially if the target of the rant ignores it. From a business perspective, giving you access to our lists gives you credibility that you haven't earned, and answering your attacks wastes time that we could spend on more substantive issues. Like fixing your problems. As far as support goes, we cheerfully assist any user who is able to provide detailed information about a problem. Detailed information includes a description of the system environment, a log or screen dump illustrating the problem, and any additional information that we may request. It is impossible for us to address any bug without this information, since we are not omniscient. Furthermore, we are a very small business, and, as individuals, we have other commitments including full time jobs working for other people. If you require instant attention to every bug or suspected bug, feel free to hire a software consultant and to give that consultant a copy of our code. (Subject to our license, of course.) We cannot provide that level of service, and will not try. > > As reasonable readers of this list will note, my normal response time to > > mail varies between a few hours and a few days. Since your mail was > > delivered to this system last night the mail is less than a day old, and > > thus you should NOT be complaining. > > Maybe it was delayed on its way. It left here immediately...Then again, > I don't know when kew.com picks up its MX forwarded mail?... It shouldn't matter. If you are unwilling to wait a few days for a response, hire a consultant. For the record, though, our MX forwarding record was recently mangled by UUNET, resulting in all our mail trying to force its way through a 2400 baud modem connection. Some additional delays may have resulted from this situation, and from the resulting backlog of mail on this end, for which we apologize. > > You were not notified of 1.12p because you specifically said you would > > NOT be upgrading. You were also informed if you are unhappy with our > > Yet you did not provide a fix. However, you said I was on the > announcements list.... We make no promises that we will fix any reported bugs. In fact, our documentation specifically disclaims any such promise in several places. Furthermore, given our limited time, bugs get prioritized based on the number of people affected by the problem. If you want your pet bug to move to the top of the list, hire a consultant. > > service you could receive a full refund of the money submitted. You > > have not requested a refund in the months since this offer was first > > made. > > Yes, I wasn't sure if I should let you off the hook :) Yet, although I > have not responded, I have not received neither the notice nor the > manuals.... No one else has received the manuals either. We've been trying to fix bugs instead of polishing the documentation. If you would like a refund, say so. We also reserve the right to refund your money, thus fully discharging our obligation to you, if we feel we are unable to provide the level of service you expect. We are very close to making that determination. > Yes it is a bad idea, I rather have him verify his tcp connection > elsewhere. I don't like my system turning into a beeping monster. Now, > if uupc wasn't doing this, I could care less. Given that we were attempting to verify that *your* system and *his* system could make a TCP/IP connection, I'm not sure what purpose would be served by having him telnet elsewhere. Until connections from *his* system to *your* system works, or he finds another provider with whom he can establish a connection, there is nothing further we can do to help him. > > running on port 540. Given the particular errors of the user saw, this > > not an unreasonable check. > > Not unreasonable to check if telnet to elsewhere works. However, > unreasonable to tlnet to port 540 here at this stage of debugging > considering what it does here. Practically, while it is looping like > that, service is unavailable to other users. It is a denial of > service... Sorry, we are not omniscient. This note is the first that we have heard of this looping problem. Perhaps much stress on both sides could have been avoided if you had seen fit to tell us (and the user) about this earlier? > > If the server system is UUPC/extended, the login will be reprompted for. > > Thus, this is not a major issue. > > Except, the user will turn around and claim that I may not have setup > his account....And with the next attempt, it will fail again due to the > crlf issue. In my own interactions with users, I've found that giving them lots of information works wonders. Like, "I'm sorry you weren't able to login. Another connection confused the server. It should be fine now." > > The important issue is if the user can get to the password prompt, the > > tcp/ip software works and the user can return to UUCICO and it's script > > logging to perform the remaining debugging. > > We do agree that windows ppp is not working for port 540 so far. He is > not getting here. He does not need to use telnet to verify that, the > logs here indicate that he is not connecting, and his debug log > indicated the same. I suspect the bad socket configuration being also > part of this. However, the windows ppp issue has to be resolved first. Windows PPP is not a UUPC/extended issue. If you have verified that the user has a PPP problem, then you have verified what we already suspected--it isn't our problem, and we don't have the resources to attempt to solve it. Sorry. (BTW, while I was writing this, Drew verified native Windows PPP connecting to the Internet on our system.) > > 3.1, I just tested it with a loopback connection to my own host; the log > > looks pretty much like the OS/2 run. > > ;) WinOS2 is not Windows. It is better than that :) However, the user > wants to use windows. I think it is a matter of 286/386... > > How did you setup the loopback? I would like to do that for testing new > accounts I setup. The sample permissn file on kendra has an example. Drew would also be more than happy to provide additional details. > > 12/08-18:56 uucico: UUPC/extended 1.12q (Nov 30 1995 08:05:05) > > (2) Warning ... invalid PERMISSIONS file entry ~/: > > (2) Run time library error 23 in E:\SRC\UUPC\LIB\SECURITY.C at line 759 ... > > (0) e:/public/altamira: The file or directory specified cannot be found. > > . > > . (several of these deleted) > > Do those lines also include error messages on OS/2 APIs? The API error is because directories that don't exist appear in the permissns file. It is not relevant to your problem. No other errors appear in the missing lines. > > OS/2(R) 2.30 with UUPC/extended 1.12q (pandora.kew.com) (tcptty) > > I have been looking for 12.q and could not find it. Where is it? Beta test. Available in kendra's public directory only, order it via the listserv@kew.com. > > (0) login: login user Uffactory (The Fantasy Factory) at Fri Dec 8 18:56:58 1995 > > (4) S state = A > > (4) S state = K > > (4) ==> ^pShere=pandora > > (4) <== ^pSffactory > > (2) 1st msg from remote = Sffactory > > (2) OS/2 API error 123 in E:\SRC\UUPC\LIB\IMPORT.C at line 812 ... > > There, what are these API errors? Opening a test file to check the characteristics of the file system. Again, not relevant to your problem. > > (0) E:/UUPC/spool/locks.lck/.DUMB.TEST.NAME: SYS0123: A file name or volume label contains an incorrect character. > > (4) advancedFS: E:/UUPC/spool/locks.lck/ffactory.LCK resides on file system supporting only 8.3 names > > Now, if you had actually queued something, you may have gotten the same > error message I get with the broken connection. Can you run it with a > mail or two queued in the spool and saee if it transfers correctly. > Here, it will abort after it goes to check the incoming stream for > packet acks....'t' protocol....Note the difference plase..... As Drew noted in his mail, he did transfer work between his system and our Internet feed, using 'e' protocol. > 't' protocol seems to work in the client mode, however, fails in the > server mode due to the socket configuration error I mentioned. Older releases had bugs in the 't' procotol, the user should use the 'e' protocol which is slightly faster, anyway. Katherine -- Katherine Derbyshire UUPC/extended e-mail: docs@kew.com Chocolate Ice Cream Fund: Post Office Box 80144 Stoneham, MA 02180 USA Any system can be beaten. The trick is to turn the handle the way it's designed to go, only more so. - Keshlam the Seer, Knight of the Random Order ------------------------------ Date: Fri, 08 Dec 1995 20:06:14 GMT From: m-kemper@therefore.com Subject: hayes Optima 28.8 To: UUPC/Extended mailing list Does someone have the MDM file for this modem? Thanks Mark Kemper ------------------------------ Date: Sat, 09 Dec 1995 09:27:04 -0500 From: Software@kew.com Subject: NEWSRUN bug 1.12p To: UUPC/Extended mailing list On Fri, 8 Dec 95 20:14:46 -0700, "Ken Wiens" wrote: > > On Thu, 30 Nov 95 20:33:46 -0700, "Ken Wiens" wrote: > > > Drew Derbyshire - UUPC/Extended Support proclaims > > > > > > > > On Wed, 29 Nov 95 22:09:50 -0700, "Ken Wiens" wrote: > > > > > I'll certainly volunteer to test! Just let me know when it's > > > > > available! > > > > > > > > Coming at you, binaries only. > > Well, I've been running q for about a week now with NO more > aborts! > > I haven't reset news to see if the lopping off of the active > file problem still exists, but hope to try that out this > weekend. This problem still existed in 1.12q, our own file has been truncated several times. We're working on a two prong solution: 1) Fix the bug! 2) Writing the active file on a temporary name name, verifying the number groups written is equal to the number of groups loaded (both initially and via newgroup commands) minus the number of deletes. If this check fails, the program aborts without truncating the active file. (it's still a problem, of course, but gives a more active indication of any remaining problem.) > The newsrun aborts appear to have gone away though! Very good news. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "I don't have a living room, I have a toy shop." ------------------------------ Date: Sat, 09 Dec 1995 11:48:37 -0800 From: Software@kew.com Subject: UUPC/extended UUCICO under Windows & TCP/IP To: UUPC/Extended mailing list I just tested UUPC/extended UUCICO under native Windows 3.1; it works correctly connecting to my Internet feed via TCP/IP under native Windows 3.1 using the CompuServe WinSock.DLL. I made sure the DLL was in the search path (normally under OS/2 I keep it out of the search path, for obvious reasons), bring up CIS Mosiac under Windows, load a page to force the CIS dialer program to connect, and then run UUCICO. It as smoothly as as the test yesterday of UUCICO under OS/2 connecting to the same provider via TCP/IP and the IBM Internet connection. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "I don't have a living room, I have a toy shop." ------------------------------ Date: Fri, 8 Dec 95 20:25:12 -0500 From: uupc@mistik.express.net Subject: uupc with windows tcpip To: UUPC/Extended mailing list > > On Thu, 07 Dec 1995 12:32:06 -0500, uupc@mistik.express.net wrote: > > Has anyone got uupc extended to work over tcp with Windows? > > Yes. > > > > > Which tcpip/ppp package are you using? > > OS/2 Warp Virtual DOS and WinSock drivers. You didn't read the question carefully. Windows, not OS/2 or WinOS2 > -- > 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. > > The objective of all dedicated employees should be to thoroughly analyze all > situations, anticipate all problems prior to their occurrence, have answers for > for these problems, and move swiftly to solve these problems when called upon. > > However, when you are up to your ass in alligators it is difficult to remind > yourself your initial objective was to drain the swamp. ------------------------------ End of UUPC-Info-Request Digest ******************************