Date: Mon, 11 Dec 95 00:55:37 PST From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1995 #51 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Mon, 11 Dec 95 Volume 1995: Issue 51 Today's Topics: expire Good news (sort of) (5 msgs) OS/2 mail reader compatible with UUPC/Extended uucp; vs. Winsock? (3 msgs) 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: Fri, 08 Dec 95 20:31:26 CET From: peter@pgeck.sub.org Subject: expire To: UUPC/Extended mailing list Hi, another question: How can I tell expire to leave news for a different time in different newsgroups? I want to keep some news for a long time, others only for some hours or days. Bye Peter -- Peter Gahbler UUCP: peter@pgeck.sub.org Richard-Vosgerau-Str.3 FIDO: Peter Gahbler, 2:240/3014.2 D-24340 Eckernfoerde voice: +49 4351 86249 ------------------------------ Date: Sat, 9 Dec 95 19:14:22 -0500 From: uupc@mistik.express.net 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 Nope. Drew can write what he means. For that he knows the language sufficiently . Therefore, what he writes is what he means. Same for you although I am not sure if the documents disaster is based on your performance. > provider. The following are true statements: Nope. > > 1. The user in question is located in a foreign country. This one is true. > 2. The user in question has no knowledge of TCP/IP. This one is true. > 3. The user is attempting to connect, via TCP/IP, to your system. This one is true. > 4. Your system does not appear to be able to reliably service this > connection. This one is false. You better go back to printing my manual and don't write about things you are knowledgable with. > 5. We are unable to help the user with #3 until #4 is resolved. Nope. You refused to address his questions. I have a copy of the mail on my files. > 6. #1 and #2 further complicate attempts to resolve #3 and #4. Nope. e-mail to the user works just fine. tcp/ip makes actually everthing appear to be local. > > 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 Since you are wrong on #4, and perharps slandering us, you better go print the manuals and don't get involved in issues that are obviously over your head. > arguing about whether you are or are not a "service provider". :) It seems you can't keep what you read in your memory. The argument was about us not being his service provider for internet access. > > > 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 As you can see, it is well founded. > gives you credibility that you haven't earned, and answering your ?? Are you slandering? So far, Drew claimed on usenet that he has no user with a makefile problem. On his mailing list someone seconded my report. I still didn't see a rectification from him on usenet.....So much on the credibility. Why are you throwing stones to a rock castle when you live in a glass house? > attacks wastes time that we could spend on more substantive issues. Like > fixing your problems. :) They are your problems incidently, since the server is uupc extended... > > 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 All info you need has been provided. > small business, and, as individuals, we have other commitments including ehm, I don't consider you business. So far, you have not even been amateurs. > 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 :) Incidently, that user in Venezuella offered you such means of hiring as well. > our license, of course.) We cannot provide that level of service, and > will not try. :) *your code* is a compilaton of codes from others, mostly. > > > > 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 ;) it should not matter since it shows you wrong? > response, hire a consultant. a few days? I waited almost a year for bugs I reported and some are still not fixed. You used up my tolerance. > > 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. Of course, you never let us know about that....sounds like excuses... > > > > 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. :) Thank you for letting us know about your user policies.... I actuually think that the problems I am experiencing with your support are due to my race, name, and country of origin. > > > > 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. Hmmmm, I think you are the one who makes the docs, and Drew is the one not fixing bugs. SO, there is no excuse for your lack of documenting. > > 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 ;) I don't think so. You have a legal contract and you have to live up to it. I demand the service. > 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. wrong. see below. > > > > 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? WHat for? You are not known for providing fixes here. Instead I am trying to compile it and fix it myself. The complation did not succeed due to problems I reported. And I was told it is my problem...nobody else has it....Then somebody else reported the same....then there was silence when I asked for instructions on how to obtain output you need to determine why nothing is generated by the makefile....Then there was flames that you just had received the mail etc....then there was the revelation that your mail is queued up and being delayed for almost a week.....Ytet, there is still no instructions on the matter I received, instead I am receiving this misleading, slandering e-mail from another department at kew....do you see why you have used up my tolerance? > > > > 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." Which would affect the sevice reliability of my system, and that is my responsibility. And I am acting on that responsibility when I say no telnet to port 540. > > > > 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.) ;) "To the internet on our system"? Are you serious? However, I will instruct him to duplicate your setup, and we will see. > > > > 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. I will, thanks. > > > > (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 is the protocol at issue. Are you avoiding acknowledging that 't' does not work which would generate another bug report... > > > '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. :) There....the latest version, 12p has the same problem. So, your reference to "older versions" is misleading again. You guys have serious problems facing up to the truth it seems. > > 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: Sun, 10 Dec 1995 08:48:11 -0500 (EST) From: rwyble@alcm.org Subject: Good news (sort of) To: UUPC/Extended mailing list According to uupc@mistik.express.net: > > > You are quibbling about semantics, Drew meant you are the *UUCP* service > > Nope. Drew can write what he means. For that he knows the language > sufficiently . Therefore, what he writes is what he means. Same for > you although I am not sure if the documents disaster is based on your > performance. [ MAJOR deletions . . . ] Dammit, this thread is REALLY starting to become annoying. -- rwyble@alcm.org Richard J. Wyble ------------------------------ Date: Sun, 10 Dec 1995 09:17:00 -0700 From: ghoti@lao-tse.bohica.net Subject: Good news (sort of) To: UUPC/Extended mailing list rwyble@alcm.org writes: >Dammit, this thread is REALLY starting to become annoying. Got that right. It's better left for private email. Any "highlights" that may be of interest to the rest of us could be put in the mailing list. -- ------------------------------ Date: Sun, 10 Dec 1995 23:52:32 -0500 From: docs@kew.com Subject: Good news (sort of) To: UUPC/Extended mailing list Mr. Soysal: Several other users of our mailing list have requested that we expel you from the list, as they do not wish to receive your statements. We are taking this request under advisement. Meanwhile, please send any reports of specific problems, or complaints regarding our level of service, to help@kew.com. Please send questions of general interest regarding UUPC/extended to uupc-info@kew.com. Failure to follow the above guidelines will result in refund of your registration fee and expulsion from all Wonderworks mailing lists. As for your comments alleging slander, discrimination, impingement of your First Amendment rights, and so on, we suggest your attorneys contact us regarding any formal action you wish to take. If you do not wish to take formal action, please be aware that repeated public threats to sue are themselves actionable as harassment and, in some cases, slander or libel. Sincerely, Katherine Derbyshire -- Katherine Derbyshire UUPC/extended e-mail: docs@kew.com Chocolate Ice Cream Fund: Post Office Box 80144 Stoneham, MA 02180 USA How can you tell a blonde has been using a computer? There's white-out on the screen. ------------------------------ Date: Mon, 11 Dec 1995 00:34:06 -0500 From: uupcinfo@kew.com Subject: Good news (sort of) To: UUPC/Extended mailing list This is the last message on this topic, because UUPC-Info will be shutdown for a few days until I can convert it to a closed list. Please bear with me. Messages sent to the list will queue until I can reopen it. Anyone who wants Mustafa to be quiet and to submit bugs directly to software@kew.com, please send him mail directly; I will not pass such items through the list when it opens up again. On Sat, 9 Dec 95 19:14:22 -0500, uupc@mistik.express.net wrote: > > On Fri, 8 Dec 95 20:55:44 -0500, uupc@mistik.express.net wrote: > > You are quibbling about semantics, Drew meant you are the *UUCP* service > > Nope. Drew can write what he means. For that he knows the language > sufficiently . Therefore, what he writes is what he means. Same for > you although I am not sure if the documents disaster is based on your > performance. I specifically corrected Katherine on that point when she asked me to proofread her note. There's gold band on my left hand that she gave me, and she wears my ring as well. Don't EVER think you know more about me than she does. > > 1. The user in question is located in a foreign country. > > This one is true. > > > 2. The user in question has no knowledge of TCP/IP. > > This one is true. > > > 3. The user is attempting to connect, via TCP/IP, to your system. > > This one is true. > > > 4. Your system does not appear to be able to reliably service this > > connection. > > This one is false. You better go back to printing my manual and don't > write about things you are knowledgable with. You will get your manual when we do a press run for all our users, and not before, since we refuse to send you less than a finished product. There is no reason to do so, especially given you can view/print the work in progress by downloading the softcopy. > > 5. We are unable to help the user with #3 until #4 is resolved. > > Nope. You refused to address his questions. I have a copy of the mail > on my files. No, we attempted to answer his questions and determined we did not have the resources to handle him. We then told him to obtain a local consultant and told him our conversation was complete. > > 6. #1 and #2 further complicate attempts to resolve #3 and #4. > > Nope. e-mail to the user works just fine. tcp/ip makes actually > everthing appear to be local. When I say local, I _mean_ local with hands on the keyboard. There are systems I personally installed for my family that I cannot do problem determination on remotely for certain things, even though e-mail works on them. Nor TCP/IP is not a major improvement, especially on a system you can't even log into like a PC. Any UNIX hacker who had to reboot a wedged system from the console knows exactly what I am talking about. > So far, Drew claimed on usenet that he has no user with a makefile > problem. On his mailing list someone seconded my report. I still > didn't see a rectification from him on usenet.....So much on the > credibility. Why are you throwing stones to a rock castle when you > live in a glass house? I'm not GOING to rectify it on Usenet, because no one cared enough to even suggest a second example of the failure. I'm going to rectify it in the Makefile, where it matters. I will fix the bug, if you send me the debugging infromation I requested _and_ it's enough to solve the problem. Otherwise it has to wait until I buy Visual Age C++, which would be zero to six months. (Windows NT users had a similar problem last year, as I had to wait six months to buy VC++ for NT. So don't bother saying I'm biased against OS/2 users, too.) > All info you need has been provided. No, it has not. We have not seen the foreign user's TCP/IP installation, been able to run diagnostics on his system including checking general response time and performing trace routes to his UUCP provider (you), and verifying his actual UUPC/extended installation. (The rate for doing so would be around $125-200/hour, plus all expenses, minimum charge being 20 hours because of the travel distance.) > > 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 > > :) Incidently, that user in Venezuella offered you such means of hiring > as well. See above. > > our license, of course.) We cannot provide that level of service, and > > will not try. > > :) *your code* is a compilaton of codes from others, mostly. Depends on how you look at it. The new news code we received was wonderful ... and I had to rewrite major portions anyway. Ditto for most of the code we've received. The only piece I don't go near is UUTRAF, because it's impossible to maintain at all. If it ever breaks, I'll have write a new one. > :) Thank you for letting us know about your user policies.... I > actuually think that the problems I am experiencing with your support > are due to my race, name, and country of origin. We don't know your race _or_ your country of origin. How could we be biased against them? (As for your name, it's no more unique than half our users, whom, as I have previously pointed out, come from around the globe.) > > No one else has received the manuals either. We've been trying to fix > > bugs instead of polishing the documentation. > > Hmmmm, I think you are the one who makes the docs, and Drew is the one > not fixing bugs. SO, there is no excuse for your lack of documenting. I write, she edits, so she waits on me. We also both answer mail, even this stuff. We also both work for living. > > 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 > > ;) I don't think so. You have a legal contract and you have to live up > to it. I demand the service. Your registration form, from version 1.11v, says you can call us on the phone for support, something like this: Send us $20 and you can call us for telephone support at the UUPC/extended support telephone number [617-279-9812] for 18 months. We'll even return your phone calls in the United States. This was the text as far back as 1.11q except for the phrase "for 18 months". I found a 1.11q copy in the file, and the version above is what we use today in 1.12p. The other check you sent was a gift, and I informally offered to send you the docs when available (as a kind gesture) ... and they are not ready yet. However, we have fulfilled our legal obligation to you. Why you would rather post on Usenet than call us or send help mail to report problems is beyond me, just as why would you rather _I_ posted on Usenet than fixed bugs is beyond me. > > 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.) > > ;) "To the internet on our system"? Are you serious? We have two systems, if that's what confused you. I used our server system verified UUCICO using CIS WinSock under Windows 3.1 would connect to our regular UUCP feed via TCP/IP while she happened to be composing that note on the portable system. > > Older releases had bugs in the 't' procotol, the user should use the 'e' > > protocol which is slightly faster, anyway. > > :) There....the latest version, 12p has the same problem. So, your > reference to "older versions" is misleading again. You guys have > serious problems facing up to the truth it seems. The truth is the official code fix at the bottom of this note; I extracted it from the RCS source archives on kendra. Unless your client is running 1.12m or above, he's DOA with 't' protocol and should run the faster 'e' protocol. If other problems exist with 't' protocol, demonstrate with it a log and a comparision log of 'e' protocol to show it is in fact the protocol module. To be complete: A problem was reported with 't' protocol after transferring 50M or so, BTW ... the user declined to provide a log, since he wanted to get work done and 'e' protocol works fine for him. So the problem has not been reproduced, and certainly doesn't mirror your client's problem. *** dcptpkt.c 1994/02/20 19:11:18 1.10 --- dcptpkt.c 1995/02/23 04:27:54 1.13 *************** *** 5,11 **** /*--------------------------------------------------------------------*/ /*--------------------------------------------------------------------*/ ! /* Changes Copyright (c) 1989-1994 by Kendra Electronic */ /* Wonderworks. */ /* */ /* All rights reserved except those explicitly granted by */ --- 5,11 ---- /*--------------------------------------------------------------------*/ /*--------------------------------------------------------------------*/ ! /* Changes Copyright (c) 1989-1995 by Kendra Electronic */ /* Wonderworks. */ /* */ /* All rights reserved except those explicitly granted by */ *************** *** 17,26 **** /*--------------------------------------------------------------------*/ /* ! * $Id: dcptpkt.c 1.10 1994/02/20 19:11:18 ahd v1-12k $ * * Revision history: * $Log: dcptpkt.c $ * Revision 1.10 1994/02/20 19:11:18 ahd * IBM C/Set 2 Conversion, memory leak cleanup * --- 17,35 ---- /*--------------------------------------------------------------------*/ /* ! * $Id: dcptpkt.c 1.13 1995/02/23 04:27:54 ahd v1-12q $ * * Revision history: * $Log: dcptpkt.c $ + * Revision 1.13 1995/02/23 04:27:54 ahd + * Explicitly report timeouts, compiler warning cleanup + * + * Revision 1.12 1995/01/07 16:38:47 ahd + * Change boolean to KWBoolean to avoid VC++ 2.0 conflict + * + * Revision 1.11 1994/12/22 04:13:38 ahd + * Correct 't' protocol processing to use 512 messages with no header + * * Revision 1.10 1994/02/20 19:11:18 ahd * IBM C/Set 2 Conversion, memory leak cleanup * *************** *** 71,80 **** /* followed by the packet data itself. No padding is */ /* performed. */ /* */ ! /* Note: Many of the functions (msg write, msg read, start */ ! /* of file, file eof) for this protocol are as the same as */ ! /* the functions for 'g' protocol, and we use the actual 'g' */ ! /* protocol copies as defined in dcpsys.c. */ /*--------------------------------------------------------------------*/ /*--------------------------------------------------------------------*/ --- 80,89 ---- /* followed by the packet data itself. No padding is */ /* performed. */ /* */ ! /* Note: A few of the functions (start of file, file eof) */ ! /* for this protocol are as the same as the functions for */ ! /* 'g' protocol, and we use the actual 'g' protocol copies */ ! /* as defined in dcpsys.c. */ /*--------------------------------------------------------------------*/ /*--------------------------------------------------------------------*/ *************** *** 104,109 **** --- 113,121 ---- #include "pwinsock.h" #endif + #define TPACKETSIZE 512 + #define TBUFSIZE 1024 + #ifndef _WINSOCKAPI_ /*--------------------------------------------------------------------*/ *************** *** 167,175 **** #pragma argsused #endif ! short topenpk(const boolean master) { ! s_pktsize = r_pktsize = 1024; /* Fixed for 't' procotol */ return DCP_OK; --- 179,194 ---- #pragma argsused #endif ! short topenpk(const KWBoolean master) { ! s_pktsize = r_pktsize = TBUFSIZE; ! /* Fixed for 't' procotol */ ! ! printmsg(4, "topenpk: Timeout = %d sec, buffer size = %d bytes, " ! "packet size = %d bytes", ! M_tPacketTimeout, ! TBUFSIZE, ! TPACKETSIZE ); return DCP_OK; *************** *** 192,198 **** return -1; } ! recv = (short) ntohl( nrecv ); if ( recv > r_pktsize ) { --- 211,217 ---- return -1; } ! recv = (unsigned short) ntohl( nrecv ); if ( recv > r_pktsize ) { *************** *** 212,218 **** remote_stats.packets++; ! *bytes = recv; return 0; --- 231,237 ---- remote_stats.packets++; ! *bytes = (short) recv; return 0; *************** *** 234,240 **** if ( ! len ) printmsg(4,"tsendpkt: Sending empty packet"); ! else if ( swrite( ip , len ) != len ) return -1; remote_stats.packets++; --- 253,259 ---- if ( ! len ) printmsg(4,"tsendpkt: Sending empty packet"); ! else if ( swrite( ip , (unsigned short) len ) != (int) len ) return -1; remote_stats.packets++; *************** *** 253,255 **** --- 272,363 ---- { return DCP_OK; } /* tclosepk */ + + /*--------------------------------------------------------------------*/ + /* t w r m s g */ + /* */ + /* Send a message to remote system */ + /*--------------------------------------------------------------------*/ + + short twrmsg( char *s ) + { + + size_t len = strlen(s) + 1; + + /*--------------------------------------------------------------------*/ + /* Write the actual message out */ + /*--------------------------------------------------------------------*/ + + if (swrite( s, len ) < (int) len ) + { + printmsg(0, "twrmsg: message write of %d bytes failed", len); + return -1; + } + + /*--------------------------------------------------------------------*/ + /* Write out as bytes as needed to pad the total data length */ + /* to TPACKETSIZE */ + /*--------------------------------------------------------------------*/ + + len = TPACKETSIZE - ( len % TPACKETSIZE ); + /* Determine bytes needed to + round out a full packet */ + + if ( len ) + { + char buf[TPACKETSIZE]; + + memset( buf, '\0', len ); /* Helps data compression */ + + if (swrite( buf, len ) < (int) len ) + { + printmsg(0, "twrmsg: write of %d padding bytes failed", len); + return -1; + } + + } /* if ( len ) */ + + remote_stats.packets++; + return(0); + + } /* ewrmsg */ + + /*--------------------------------------------------------------------*/ + /* t r d m s g */ + /* */ + /* Read a message from the remote system */ + /*--------------------------------------------------------------------*/ + + short trdmsg( char *s) + { + + size_t bytes = 0; + + while (sread( s + bytes, + TPACKETSIZE, + M_tPacketTimeout) == TPACKETSIZE ) + { + int column; + + remote_stats.packets++; + + for ( column = 0; column < TPACKETSIZE; column ++ ) + { + if ( s[ bytes + column ] == '\0' ) /* End of the string? */ + return 0; /* Yes --> Report success */ + } + + bytes += TPACKETSIZE; + + } /* while */ + + /*--------------------------------------------------------------------*/ + /* We didn't get the end of the string in time, report an error */ + /*--------------------------------------------------------------------*/ + + printmsg(0, "trdmsg: Command read failed with %d bytes read", + (int) bytes ); + + return -1; + + } /* trdmsg */ -- 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. VM programmers do it virtually all the time. ------------------------------ Date: 10 Dec 1995 00:00:00 +0000 From: hajo@quijote.in-berlin.de Subject: OS/2 mail reader compatible with UUPC/Extended To: UUPC/Extended mailing list Hallo JR Lee, Du schriebst am 08.12.95: > Does anybody here knows a good OS/2 mail reader compatible with > UUPC/Extended? Apparently, the one that I am using which is ELM > 2.3.11 lacks of certain function. And since I use accented > characters or extended ASCII set characters very often, it made it > inconvienient for me to use ELM. I hope someone can suggest a good > alternative. This is a problem, and I gave up on UUPC for this some days ago. Luckily, there is some hope. There will be at least MIME ISO 8859-1 support (which do you need in .sg?), and I have just finished a description how to support UUPC with this email package. I guess we'll see something within the next month, but - I'm not the programmer, don't shoot me. :-) hajo P.S.: You might not want to shoot the programmer either. -- ----[Hans-Joachim Zierke ]---------------------------------------------- [Rathenower Strasse 23 ] [D-10559 Berlin-Moabit] hajo@quijote.in-berlin.de [ +49-30 / 394 84 45] ----[Fax:(0)30 / 394 84 47]---------------------------------------------- ------------------------------ Date: Sun, 10 Dec 95 15:20:57 CST From: guthrie@mum.edu Subject: uucp; vs. Winsock? To: UUPC/Extended mailing list I have been a UUCP user for many (previous) years, and think that uupc is a great tool and provides a lot of capabilities for users. But, I wonder why today would anyone choose uucp/pc over SLIP/PPP? It is my impression that uucp came from the 1970's, remained in the '80s, but that now in the '90s the standatd for networking has changed. In this group I see a lot of requests for GUI mail programs, internet mail transport, etc.. that would all seem to be most easily satisfied by a standard Winsock+Eudora setup. Win-95 now provides transparent peer-peer networking and resource sharing, dial-in, SLIP/PPP, etc. As an honest open inquery, what is the role/value of uucp in todays technical environment? What does/can it do better/easier than contemporary wnetworking tools? ------------------------------------------ Gregory Guthrie ------------------------------------------ ------------------------------ Date: Sun, 10 Dec 95 20:24:38 CST From: guthrie@mum.edu Subject: uucp; vs. Winsock? To: UUPC/Extended mailing list On 10 Dec 1995 19:26:04 -0500 Michael Zboray wrote: > Reply to: RE>uucp; vs. Winsock? > >Well, >If you have a permanent IP connection, your right. >Most of us can't aford a permanent IP connection and with UUCP >you can collect mail at midnight and have it all on your hardisk when >you wake up. >Works really well for mail and NEWS. >reading news off of local hard disk after it was collected off line >is much faster than waiting online. Note that dial-up and spooling of mail and news, with offline processing and reading is also standard with Winsock and its tools. The two most popular email tools Eudora & Pmail both support offline modes, and most popular news tools also do. Timed batch access does require a "cron" like tool, but that's easy. I think that VERY few users have permanent connections, almost all networking of this type is dial-up, and much of that in a batch mode (as you describe). On Mon, 11 Dec 1995 13:39:34 -1200 Stephen Worthington wrote: > >Well, at work we do not have a PPP connection. > ...< similar points about batch offline reading > .... This implies that you DO have a uucp connections, it is surprising to find vendors that don't have either SLIP or PPP these days, and generally equally rare for vendors to support uucp. Interesting. ------------------------------------------ Gregory Guthrie ------------------------------------------ ------------------------------ Date: 11 Dec 1995 00:00:00 +0000 From: hajo@quijote.in-berlin.de Subject: uucp; vs. Winsock? To: UUPC/Extended mailing list Hi Gregory, Du schriebst am 10.12.95: > I have been a UUCP user for many (previous) years, and think that uupc > is a great tool and provides a lot of capabilities for users. I don't use it, but prefer my old DOS program. In my old DOS program, bsmtp support is a checkmark to switch. With UUPC, it will be configuring sendmail.cf. Nonetheless, I think I will switch to UUPC next year, if there are good clients for mail and news. As soon as I get rid of it, I can switch off all DOS and Windows support: PROTECTONLY=YES. And I could buy a Digiboard then. > But, > I wonder why today would anyone choose uucp/pc over SLIP/PPP? To avoid getting poor, and to speed up newsreading. Next year, the TELEKOM will lower the long-distance rates, and double the rates for local calls. Transfer efficiency in getting news is crucial therefore, and there is nothing more efficient than news in _big_ batches, with gzip run over it. 1) You will never match gzip with V42b. 2) The TCPIP protocol gives far more overhead than 1024,7,variablepacket. Real-world figures for V32bis modems might be 1530 - 1540 cps for compressed data on TCPIP links, 1640 with UUCP. 3) If you want to transfer news with IhaveSendMe or in newsreader mode, you need considerable time to start the connection. BTW: The local private newsservers went back from IHave-SendMe to UUCP via TCPIP, because they cannot run an all.all feed with the delays of their ISDN connection and IHave-SendMe. They can't get more than 85000 articles per day, while UUCP can feed them more, even with all the history file throwaway. News have to be local. With more and more news, there has to be faster access and more filters. This works well with fast Ethernet, but you can't do this with a V34 link. You can do this with a news database on your own harddrive, though maybe not if you downgraded to Windows 95. On VFAT, some tenthousand articles won't make you happy, but both OS/2 and WinNT can work as a newsserver. You can run a news database with big files on Win95, though. Finally, SLIP is not a protocol. It was never intended to be, the writer of SLIP warned everybody not to use it like a protocol. Modem error correction makes it work not too bad. But hangup is undefined, and using it dialup for unattended work is very risky. PPP is a little better, though. If you get some points, it is not for shortcomings of UUCP, but for shortcomings of UUPC. If you have major traffic both ways, PPP is faster, because UUPC does not support uucp-i. rmail transport is utterly unefficient. But at least for the OS/2 platform, this might get replaced by gbsmtp in 1996. Since every OS/2 is delivered with a Sendmail Server, most of the work can be configured in a file that's everybodies darling: sendmail.cf. :-) 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]---------------------------------------------- ------------------------------ End of UUPC-Info-Request Digest ******************************