Xref: utzoo unix-pc.general:4455 unix-pc.uucp:211 comp.sys.att:8414 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!rutgers!cs.utexas.edu!uunet!lll-winken!scooter!neoucom!wtm From: wtm@neoucom.UUCP (Bill Mayhew) Newsgroups: unix-pc.general,unix-pc.uucp,comp.sys.att Subject: Re: UUCP Help Summary: I've had problems with setting CLOCAL in BNU Message-ID: <1867@neoucom.UUCP> Date: 7 Jan 90 17:47:26 GMT References: <25553@cup.portal.com> <25594@cup.portal.com> <346@pattye.lonestar.org> Organization: Northeastern Ohio Universities College of Medicine Lines: 71 I'll have to give AT&T credit. The V2.1 uucp system that comes bundled with the UnixPC made a lot of improvements, most notably the modemcap file which makes it farily easy to set up modem dialer chat scripts. Anybody that has worked with an older Unix or Xenix knows what a pain it is to have to write dialer programs. I would also like to criticize AT&T's v2.1 uucp for the 3b1 in particular. Uucico likes to cause kernel panics at odd intervals under non-repeatable circumstances. It seems to be related to using both the tty ports and the OBM (on board modem) (and not necessarily simultaneously). People that use either the tty or the OBM only don't seem to get the panics. Whatever causes the panic is goofy, as fron my recollection, the panics occur at an odd numbered address, which should not happen. It has been a while, so I don't remember the numbers any longer. I have to give credit to the Hotline, as they tried emailing me several replacement uucicos with various fixes, none of which, unfortunately, helped. AT&T even swaped the motherboard in my machine, which also did not help. Soembody from tier III support, or whatever it is called, had read a usenet article I posted and called me for information separately from the hotline's effort to resolve my trouble ticket. So... I was pleased with the service I got from AT&T, but it didn't solve my problem. What did away with the kernel panics was installing the unofficial BNU on my 3b1. Per the recent discussion of \M and \m to set ONDELAY open CLOCAL and unset it respectively: yes, the aforementioned tokens are documented in the comments as the top of the Dialers file. Of course, there is no printed documentation for BNU, but considering the cost, you get what you pay for.... However.... I tried using \M to set CLOCAL as the first token in my modem chat script, and it doesn't work for me. When I run BNU in debug mode, I see the "mlock tty000 succeeded" and then the script times out where the "processdev(..." should be with a "CAN NOT ACCESS DEVICE". If I tie the DCD pin high, the script succeeds and I do indeed see a CLOCAL SET where dialing begins. I use a trailblazer modem, which enables me to do a work-around. I set S53=4, which makes the modem hold DCD high all the time (which happens to be irrelevent for this purpose) and hold DSR high except for a brief period (specified by S47) when the carrier is lost. I would normally use a cable that wires 1,2,3,4,5,6,7,8,20 straight through between the modem and 3b1. For this I leave 8 on the modem end unconnected and run 6 from the modem end to both 6 and 8 on the 3b1 end; all other wires straight through. I suspect that my problems might arise from the fact that I run uugetty on the port with the gettydefs with CLOCAL off so that disconnected calls drop cleanly. That fact means that the chat script is enter with CLOCAL off before the first token is processed. Anyway, I'm happy that I can get things to work properly with my trailblazer modem. People that have Hayes or exact clone modems, it would seem, are in for more aggrivation if they want to use BNU and uugetty. If you're willing to not have a bidirectional port, then life would be somehwat easier I suspect. As for the real documentation from AT&T goes, the BNU docs that come with the 6386's Sys V r3.2, which is the newest release we have, are vastly superior to anything in the past. None the less, a neophyte to port settings, CLOCAL, ONDELAY, etc, would probably have a tough time. I suppose that's what makes job opportunities for people like ourselves that hypothetically know what we are doing. Bill