mrm@sceard.Sceard.COM (M.R.Murphy) (05/05/91)
I've a friend with a 3B1 using OBM to attempt UUCP connection to two systems, each with a TB (one TB+, one 2500). The TB+ system is HDB, locked interface speed 9600baud, hardware flow control. The TB2500 is HDB, locked interface speed 19.2Kbaud, hardware flow control. The TB systems talk fine with systems with 1200baud external Hayes clones, as well as with various 2400baud, 9600baud V.32, and PEP sites, and with each other. The 3B1 will not successfully complete a UUCP session with either TB system. A representative log entry from one of the TB sites is: uucp sitename (5/4-0:55:20,23357,0) OK (startup) uucp sitename (5/4-0:58:50,23357,0) BAD READ (expected 'H' got FAIL) uucp sitename (5/4-0:58:50,23357,0) FAILED (conversation complete) I've been told that the 3B1 is using 3.51. I thought I'd ask for words of wisdom before digging to find out what might be going amiss on the 3B1 (a machine I can recognize by sight:-) end. I figure this might be a common and easily recognizable symptom to folks with experience. Thanks for any help, Mike -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
zaft@slced1.nswses.navy.mil (Gordon C Zaft) (05/05/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >I've a friend with a 3B1 using OBM to attempt UUCP connection >to two systems, each with a TB (one TB+, one 2500). The TB+ >system is HDB, locked interface speed 9600baud, hardware flow >control. The TB2500 is HDB, locked interface speed 19.2Kbaud, >hardware flow control. The TB systems talk fine with systems >with 1200baud external Hayes clones, as well as with various >2400baud, 9600baud V.32, and PEP sites, and with each other. The >3B1 will not successfully complete a UUCP session with either TB >system. A representative log entry from one of the TB sites is: I believe the notes in osu-cis say that this won't work because the OBM makes noises that the TB+ thinks is PEP but aren't. Perhaps one of the Experts will elaborate further? -- + Gordon Zaft | zaft@suned1.nswses.navy.mil + + NSWSES, Code 4Y33 | suned1!zaft@elroy.jpl.nasa.gov + + Port Hueneme, CA 93043-5007 | Phone: (805) 982-0684 FAX: 982-8768 + ** ..et resurrexit tertia die secundum scripturas, et ascendit in coelum.. ***
bruce@balilly (Bruce Lilly) (05/05/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >I've a friend with a 3B1 using OBM to attempt UUCP connection >to two systems, each with a TB (one TB+, one 2500). The TB+ >system is HDB, locked interface speed 9600baud, hardware flow >control. The TB2500 is HDB, locked interface speed 19.2Kbaud, >hardware flow control. [ ... ] This is a well-known problem with Telebit modems (at least the TB+) when operated with the interface speed locked. The Telebit puts out a non-standard signal, which causes the 3B1's built-in modem to receive garbage (the 3B1's OBM is rather intolerant of non-standard signals). Telebit refers to this bug as "bit-shaving". If you turn on UUCP debugging, you'll see that the first couple of dozen characters are received OK, then only garbage is received. You can also verify this using cu. Your options are: 1) don't operate the Telebit's with interface speed locked 2) try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck) 3) trade in the Telebits for another brand of modem 4) use an external modem on the 3B1 which will accept the Telebit's non-standard timing Unfortunately, if you don't have control of the systems being dialed into, options 1,2, and 3, which are various attempts to solve the problem at the source, are not available. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
dave@das13.snide.com (Dave Snyder) (05/06/91)
In article <1991May4.210605.28387@sceard.Sceard.COM>, mrm@sceard.Sceard.COM (M.R.Murphy) writes: > I've a friend with a 3B1 using OBM to attempt UUCP connection > to two systems, each with a TB (one TB+, one 2500). The TB+ > system is HDB, locked interface speed 9600baud, hardware flow > control. The TB2500 is HDB, locked interface speed 19.2Kbaud, > hardware flow control. The TB systems talk fine with systems > with 1200baud external Hayes clones, as well as with various > 2400baud, 9600baud V.32, and PEP sites, and with each other. The > 3B1 will not successfully complete a UUCP session with either TB > system. A representative log entry from one of the TB sites is: > Interesting how this keeps coming up. I must confess, I asked the same question about six months ago. Anyway, the bottom line is... the OBM on a 3B1 will not connect to a Telebit if the modem is using locked interface speeds. The only way for an OBM to connect to a Telebit is to have the Telebit allow auto-bauding. I remember hearing of someone that rewrote getty (or was it uugetty?). I'm pretty sure that this getty (or whatever) solved the problem with out auto-bauding. DAS -- David A. Snyder @ Snide Inc. - Folcroft, PA UUCP: ..!uunet!das13!dave INTERNET: dave@das13.snide.com
bdb@becker.UUCP (Bruce D. Becker) (05/06/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: |I've a friend with a 3B1 using OBM to attempt UUCP connection |to two systems, each with a TB (one TB+, one 2500). The TB+ |system is HDB, locked interface speed 9600baud, hardware flow |control. The TB2500 is HDB, locked interface speed 19.2Kbaud, |hardware flow control. The TB systems talk fine with systems |with 1200baud external Hayes clones, as well as with various |2400baud, 9600baud V.32, and PEP sites, and with each other. The |3B1 will not successfully complete a UUCP session with either TB |system. A representative log entry from one of the TB sites is: The Telebit does something different when running with interface speed locked, such that connections to 3B1 OBM's won't work. Apparently connection is possible when it runs with unlocked interface, and without flow control.
gandrews@netcom.COM (Greg Andrews) (05/06/91)
In article <98083@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >|I've a friend with a 3B1 using OBM to attempt UUCP connection >|to two systems, each with a TB (one TB+, one 2500). [parts of description deleted] >|The 3B1 will not successfully complete a UUCP session with either TB >|system. A representative log entry from one of the TB sites is: > > The Telebit does something different when > running with interface speed locked, such > that connections to 3B1 OBM's won't work. > Apparently connection is possible when it > runs with unlocked interface, and without > flow control. > The most common problem is that the OBM barfs big-time on the Telebit PEP answer tones. The normal way to handle this is to set the Telebit modems to issue the PEP answer tones last (S92=1). The OBM sees just the usual 2400/1200 answer tones and is happy ever after. The thing that Telebit modems do differently with a locked interface speed is perform "stop bit deletion". This is a condition where the transmitting modem leaves off a character's stop bit once in a while, and the receiving modem puts the stop bit back on the character before passing it on to the computer. This is done every 8th character by Telebit modems. However: Stop bit deletion is allowed in the 'specification' (actually the correct term is recommendation) for V.22bis, and that's the only type of connection where Telebit modems delete stop bits. V.22bis is the 2400 bps modulation. A modem that can't handle missing stop bits would seem to be not fully compliant with V.22bis. As far as I know, the OBM is a *1200* bps modem, using the Bell 212 or maybe the V.22 modulation. I'm not aware of any 2400 bps OBMs. Telebit modems don't do stop deletion for Bell 212 connections, so I can't see where that would affect an OBM. I think M.R.'s problem is more likely due to the OBM having trouble with the PEP answer tones rather than stop bit deletion. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/06/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >[Friend has difficulty between 3B1's OBM and trailblazers] This C program, in addition to setting the line to tone dial (mine won't thru "normal" channels for some reason, sets PIOCOVSPD on the modem which permits it to talk to trailblazers. #! /bin/sh # This is a shell archive. Remove anything before this line, then feed it # into a shell via "sh file" or similar. To overwrite existing files, # type "sh file -c". # The tool that generated this appeared in the comp.sources.unix newsgroup; # send mail to comp-sources-unix@uunet.uu.net if you want that tool. # Contents: phfix.c # Wrapped by clewis@ecicrl on Mon May 6 00:57:58 1991 PATH=/bin:/usr/bin:/usr/ucb ; export PATH echo If this archive is complete, you will see the following message: echo ' "shar: End of archive 1 (of 1)."' if test -f 'phfix.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'phfix.c'\" else echo shar: Extracting \"'phfix.c'\" \(1136 characters\) sed "s/^X//" >'phfix.c' <<'END_OF_FILE' X/* Sample program for bashing the OBM into tone dial and X setting PIOCOVSPD to permit talking to certain modems X (particularly telebits). X The documentation mentions 2.3% speed change for PIOCOVSPD. X That's all I know. X X You are free to do whatever you wish with this code, but X please leave this comment in. X X Chris Lewis, clewis@ecicrl.uucp, Jan 2 1991. X */ X#include <stdio.h> X#include <fcntl.h> X#include <sys/phone.h> X Xmain(argc, argv) Xint argc; char **argv; { X int f; X struct updata upd; X f = open("/dev/ph1", O_RDWR | O_NDELAY, 0); X if (f < 0) { X perror("/dev/ph1"); X exit(1); X } X ioctl(f, PIOCGETP, &upd); /* retrieve Phone parameters */ X upd.c_lineparam &= ~PULSE; /* reverse the sense to set to pulse dial */ X upd.c_lineparam |= DTMF; /* reverse the sense to set to pulse dial */ X X#ifdef NEVER X upd.c_feedback |= SPEAKERON; X upd.c_feedback |= LOUDSPK; X ioctl(f, PIOCDISC, &upd); /* apply PIOCOVSPD for talking to some modems*/ X#endif X X ioctl(f, PIOCOVSPD, &upd); /* apply PIOCOVSPD for talking to some modems, X eg: Telebits */ X ioctl(f, PIOCSETP, &upd); /* set phone parameters */ X} END_OF_FILE if test 1136 -ne `wc -c <'phfix.c'`; then echo shar: \"'phfix.c'\" unpacked with wrong size! fi # end of 'phfix.c' fi echo shar: End of archive 1 \(of 1\). cp /dev/null ark1isdone MISSING="" for I in 1 ; do if test ! -f ark${I}isdone ; then MISSING="${MISSING} ${I}" fi done if test "${MISSING}" = "" ; then echo You have the archive. rm -f ark[1-9]isdone else echo You still must unpack the following archives: echo " " ${MISSING} fi exit 0 -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/07/91)
Dave Snyder wrote: |>[about Mike Murphy's friend's failure to connect to a locked Telebit from the OBM] |I asked the same question about six months ago. Anyway, the bottom line is... |the OBM on a 3B1 will not connect to a Telebit if the modem is using locked |interface speeds. The only way for an OBM to connect to a Telebit is to have the |Telebit allow auto-bauding. Bruce Lilly wrote: |This is a well-known problem with Telebit modems (at least the TB+) when |operated with the interface speed locked. The Telebit puts out a |non-standard signal, which causes the 3B1's built-in modem to receive |garbage (the 3B1's OBM is rather intolerant of non-standard signals). |Telebit refers to this bug as "bit-shaving". |Your options are: |1) don't operate the Telebit's with interface speed locked |2) try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck) |3) trade in the Telebits for another brand of modem |4) use an external modem on the 3B1 which will accept the Telebit's | non-standard timing The phfix program I just posted solved Mike's friend's problem - I just got e-mail from him thanking me for it. I've been using it to connect to my feed (a Sun with a locked speed T2500) for about 5 months. The principle trick is the PIOCOVSPD ioctl. About 6 months ago someone posted something about a OBM utility that he was writing but hadn't finished and mentioned the PIOCOVSPD ioctl in passing, which is where I got the idea to try it. Thank you whoever you were. Phfix was written without docs (so I had to guess at the invocations) to solve the TB problem as well as for some reason the builtin software could no longer set the modem to tone dial. It could use some cleanup by someone who knows the right ioctl invocations. On my system I've installed the invocation of phfix in the /etc/rc near the end. It seems to work "permanently" - ie: it only has to be invoked once on boot. However, I seem to remember someone telling me that phfix will not work with HDB UUCP on the 3b1 because HDB clobbers the setting each time it starts. However, I've experimented a bit, and have found that you can invoke phfix *during* the uucico run to clear the problem. Ie: you start up uucico, and you notice that it's starting to alarm out - at this point you can invoke phfix and the uucico will resync and continue normally. So, you might be able to kludge in a mechanism by which phfix is invoked a fixed time after you've fired up uucico. Alternately, you could modify phfix into a "daemon" to sit quiescent, stat'ing (or access()) the LCK* file[s] for the TB sites every 30 seconds or so. Once it notices a LCK file for the site[s] that has the locked speed TB, then it starts PIOCOVSPD'ing the OBM every 10-15 seconds for 2 minutes. That oughta fix it without putting too much load on the machine. Alternately, those guys who seem to like doing binary debugging might want to work out a binary patch for HDB. I'll be installing HDB one of these days, so maybe I'll get to kludge phfix. Further, it may very well be that phfix will work "normally" even with HDB for incoming calls - because the uucico on the receiving side is unlikely to be as "violent" with its ioctls. If anybody alters phfix.c into a HDB daemon, or simply cleans it up, please let me know. BTW: My feed has informed me that he's set his TB to lock at 1200 when it calls my 3b1. He doesn't remember why he did that. But it is certainly locked at 9600 (or is it 19200 I disremember) when I call his TB. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
root@zswamp.uucp (Geoffrey Welsh) (05/08/91)
In a letter to All, Greg Andrews (gandrews@netcom.COM ) wrote: >However: Stop bit deletion is allowed in the 'specification' >(actually the correct term is recommendation) for V.22bis, Hmmm, delete the stop bit every 8th character and you have a 1.3% throughput improvement... hardly seems worth the hassle. I suppose that the receiver modem should be able to tell if the stop bit is omitted, since a space will appear when a mark was expected... doing this every character would result in an 11.1% throughput improvement (about half of that achieved with MNP3&4 or LAP-M), for a maximum 2400 bps throughput of 267 CPS! -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
gandrews@netcom.COM (Greg Andrews) (05/08/91)
In article <1991May5.121256.4453@blilly.UUCP> bruce@balilly (Bruce Lilly) writes: > >This is a well-known problem with Telebit modems (at least the TB+) when >operated with the interface speed locked. The Telebit puts out a >non-standard signal, which causes the 3B1's built-in modem to receive >garbage (the 3B1's OBM is rather intolerant of non-standard signals). >Telebit refers to this bug as "bit-shaving". > >Your options are: >1) don't operate the Telebit's with interface speed locked >2) try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck) >3) trade in the Telebits for another brand of modem >4) use an external modem on the 3B1 which will accept the Telebit's > non-standard timing > "Good Luck" is a pretty good sentiment. Why? Because it's NOT a Telebit bug. Bruce, you can call it Telebit's "problem" and "non-standard timing" all day long, but that's simply not the case. As I mentioned in my other article, Stop Bit Deletion (and the corresponding Stop Bit Insertion) are a part of the modulation spec. The modem that can't handle re-inserting the stop bit is the one with the problem. Telebit modems can handle Stop Bit Insertion - guess which modem has the problem? As I'm at home tonight, I can't quote chapter and verse from the specs on this, but you can be certain that I will find it and quote it for you. If it turns out I'm wrong, I'll eat my words on it. My last posting was wrong on one point: Telebit modems perform Stop Bit Deletion in the Bell 212 and V.22 (1200 bps) modulations also - not just V.22bis (2400 bps). > > Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM > -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
gandrews@netcom.COM (Greg Andrews) (05/09/91)
In article <29.28280170@zswamp.uucp> root@zswamp.uucp (Geoffrey Welsh) writes: >In a letter to All, Greg Andrews (gandrews@netcom.COM ) wrote: > > >However: Stop bit deletion is allowed in the 'specification' > >(actually the correct term is recommendation) for V.22bis, > > Hmmm, delete the stop bit every 8th character and you have a 1.3% >throughput improvement... hardly seems worth the hassle. > It wasn't included for the purpose of pushing the link to higher speeds. It was done because the modem may need to contend with a terminal (or a computer) which has a baud rate clock that's running faster than a true 1200 bps. Or the modem's baud rate clock is running slower than a true 1200 bps (or whatever the modulation rate is). If the modem is receiving data nonstop from a DTE device that's running a bit fast, then it may need to drop a bit out of the modulation every so often in order to keep the pace. (remember that the modulation specs must assume the worst - the modem has no means of flow control) Dropping 1 bit out of every 80 bits (8 bytes) could compensate for up to a 1.25% speed difference. Dropping 1 bit out of every 40 bits could compensate for up to 2.5%. There's a complementary allowance for inserting extra stop bits if the DTE is running more slowly than the modem modulation. I pulled this from the V.14 recommendation, which the V.22bis and V.22 recommendations reference as their async-to-sync-and-back converter spec. I haven't found the Bell 212 stuff yet. Will summarize when I get it all together. >Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
tnixon@hayes.uucp (05/10/91)
In article <29.28280170@zswamp.uucp>, root@zswamp.uucp (Geoffrey Welsh) writes: > In a letter to All, Greg Andrews (gandrews@netcom.COM ) wrote: > > >However: Stop bit deletion is allowed in the 'specification' > >(actually the correct term is recommendation) for V.22bis, > > Hmmm, delete the stop bit every 8th character and you have a 1.3% > throughput improvement... hardly seems worth the hassle. > > I suppose that the receiver modem should be able to tell if the stop bit > is omitted, since a space will appear when a mark was expected... doing this > every character would result in an 11.1% throughput improvement (about half > of that achieved with MNP3&4 or LAP-M), for a maximum 2400 bps throughput of > 267 CPS! There seems to be some confusion here regarding stop bit deletion. CCITT V.42 (error control) deletes the start AND stop bits from EVERY character. Only the 8 data bits are transmitted, with blocks being framed with flags, frame headers, and FCS. The frames are transmitted synchronously between the modems, perfectly aligned to the carrier clock speed. The speed used on the DTE-DCE interface is independent of the line speed, and buffering and flow control are used to align the throughput on one interface to the other. What Greg is talking about is completely different -- CCITT V.14 async-to-sync conversion. V.14 is referenced by CCITT V.22, V.22bis, V.26ter, V.32, and V.32bis, and is also used in Bell 212. V.14 is for NON-error-control communications. It allows the modem to compensate for the fact that the DCE-DTE interface is asynchronous, that the clocks on the DCE and DTE may be slightly off. In V.14's "basic range", the DTE may be up to 1% "too fast" (meaning, for example, it can actually be sending up to 2424bps on a 2400bps modem), or as low as 2.5% too slow (as little as 2340bps). In the "extended range", the lower limit of -2.5% is the same, but the upper limit ("too fast") is extended to +2.3% (as high as 2455bps). If the DTE is running "too slow", the V.14 async-to-sync conversion process simply adds an additional stop bit every few characters, as necessary. That's pretty simple! The remote modem in this case doesn't do anything, really; it just delivers all the bits. If the DTE is running "too fast", and is sending lots of characters one after the other, then the DCE has a problem; it can't put that many bits onto the line, because it can only send one bit per clock cycle. So, it occassionally DELETES a stop bit (always value 1), and just starts the next character (with a start bit, always value 0). It is only permitted to do this once every eight (basic range) or every four (extended range) characters. The receiver detects that there is a start bit where there is supposed to be a stop bit, and re-inserts the stop bit. This, of course, means that the receiving DCE is having to "run fast", too, putting out more bits to its DTE than it normally would. Most DCEs accomplish this by shaving a little bit off EVERY stop bit they send to the DTE -- sending 3/4ths of a stop bit if they support the "extended" range, or 7/8ths of a stop bit if they support the "basic" range. That's fine, because the DTE samples bits at 1/2 of the time into the bit. If there's not an additional character to send, then, of course, the DCE just extends the stop bit (the usual case). The other consideration is with BREAK signalling. For this process to work, breaks must be long enough that the receiving DCE can distinguish them from two consecutive null characters with the stop bit deleted on the first one. V.14 enforces this by saying that breaks must be at least 19 bits long (assuming 8-bit characters). This "appears" to receiving modem as though the stop bits had been deleted from two consecutive characters, which is not permitted, so it doesn't re-insert the stop bits and allows "break" to pass through to the DTE unmolested. The transmitting DTE must insure that once a break is started by the DTE, that it is forced to be at least 19 bits long; otherwise, the receiving DCE will "fix it" by inserting a stop bit in the middle. V.14 is implemented in all modems by all manufacturers that support async transmission on V.22, V.22bis, V.26ter, V.32, and V.32bis; it's not a special feature (or bug!) in Telebit modems. It's not done to try to improve throughput, but to account for the inaccurate bit rate clocks used in many async terminals, PCs, and computers. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
root@zswamp.uucp (Geoffrey Welsh) (05/11/91)
In a letter to All, Greg Andrews (gandrews@netcom.COM ) wrote: GW> Hmmm, delete the stop bit every 8th character and you have a 1.3% GW>throughput improvement... hardly seems worth the hassle. >It wasn't included for the purpose of pushing the link to >higher speeds. I understood that the modems transmitted between them at 1200 bps on the nose, and to their host computers at 1219 bps. I s'pose it makes sense. Thanks. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
root@zswamp.uucp (Geoffrey Welsh) (05/12/91)
>From: tnixon@hayes.uucp >There seems to be some confusion here regarding stop bit >deletion. Not on my part; I understand the difference and was merely mumbling aloud about its possible abuses, making comparison to MNP3&4. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me