bill@twg.bc.ca (Bill Irwin) (01/27/91)
I have noticed some odd behavior on our SCO XENIX 2.3.2 system. We have three modem lines: 2 are dedicated numbers and 1 is line 3 of our regular business number. It seems the only way to get the O/S to faithfully put the LCK..ttyxxx file into /usr/spool/uucp when someone logs in on the port, is to have the port defined in the /usr/lib/uucp/Devices file as an outgoing modem line. The two dedicated modems have been in the Devices file for a long time, but the one using the business line was not (because uucp never uses it). I decided to put that port into the Devices file so the lock files would work better for that port. Also, the modem now disconnects upon log out. The morning after I did this I noticed the modem answering line 3 on our phones whenever it rang. I have a script that runs every 15 minutes and determines if it is after hours it will turn auto answer on; and if it is business hours, turn it off. This always worked fine until I added the port to the Devices file. Now, running the script shows the AA light go out on the modem, but after a few seconds (as the port is enabled again after talking to the modem) the AA comes back on again. I tried experimenting and found that if I changed the Devices dialer from hayes2400 to direct, the AA light stays out after the auto answer script is run. Change it back to hayes2400 dialer and the AA light stays on all the time. Is there something about the definition of a modem dialer that makes uugetty (or ungetty, whichever one is running) force S0=1? I would rather it leave it alone and not assume that just because a port is defined as an outgoing uucp line and it happens to be enabled, that one automatically wants the modem to answer the phone. Sign me, puzzled. -- Bill Irwin - The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | Your Computer bill@twg.bc.ca (604) 430-4329 (fax) | Systems Partner
chip@chinacat.Unicom.COM (Chip Rosenthal) (01/28/91)
In article <1810@chinacat.Unicom.COM> I blabber: >If you don't want the modem to automatically answer >the line, then you don't want it disabled. Ack! s/disabled/enabled/ -- Chip Rosenthal 512-482-8260 | If software look-and-feel can be protected, Unicom Systems Development | then I'd like to claim a copyright upon <chip@chinacat.Unicom.COM> | `Memory fault - core dumped'.
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (01/29/91)
In article <1810@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >For the binary dialers >(which are philosophically grotesque, Whyzat? Have you ever had to handle a custom DCE with, say, SUN's UUCP? Good luck. The concept of the external dialer program is quite an EXCELLENT facility. I often point to the feature as an example of the great added-value SCO offers above vanilla-UNIX. > but I still like 'em Good! ----------------------------------------------------------------------- Warren Tucker, March Hare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. -Edmund Burke
prs@tcsc3b2.tcsc.com (Paul Stath) (01/30/91)
Start-up disclaimer: I have never worked on a Xenix system before, and do not know all of the technical ins and outs. On AT&T System V, the uugetty program is kind enough to let other programs take over the line. When this happens, the program creates a lock file to signify that it has the line. After the program is finished, your AA on/off script in this case, it releases the lock file. When this happens, uugetty is respawned on the line. During this respawn of uugetty, the DTR to the modem probably drops. (You should see this happen, the Terminal Ready light goes off then on.) Most modems are configured to reset to the setup stored in memory, on a drop of DTR. This may be what is happening. When the line is not defined as an outgoing line, then regular getty is probably used, and this DTR drop does not occur. Try modifying your script to not only turn on/off AA, but also save the setting in the modem. Then when your script finishes, DTR drops, and the modem will restore the value you have just stored. Of course, this may be WAY off base. If so, you can't say I didn't warn you ;-).
bill@twg.bc.ca (Bill Irwin) (01/30/91)
chip@chinacat.Unicom.COM (Chip Rosenthal) writes: :The moral of the story is if you are going to put a modem on the :line - even if you aren't running uucp upon it - then make sure :there is a good Devices entry. I have come to the realization that the &hayes2400 entry in Dialers was running whenever the port was enabled. By specifying the hayes1200 dialer, which doesn't set S0, the problem is gone. :In article <563@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: :>I have a script that runs every :>15 minutes and determines if it is after hours it will turn auto :>answer on; and if it is business hours, turn it off. :Don't do that. If you have the line properly configured in Devices :then it will stop breaking every time somebody logs in and out. Run :enable(1) and disable(1) through cron to turn the line on and off for :incoming logins. Even if a modem line is never used for dialout -- :or even by uucp for that matter -- you should still put it in Devices. :>I would rather it leave it alone and not assume that just because :>a port is defined as an outgoing uucp line and it happens to be :>enabled, that one automatically wants the modem to answer the :>phone. :Errrr...enabling the line by definition says you want the modem to :answer the phone. If you don't want the modem to automatically answer :the line, then you don't want it disabled. [Chip meant enabled] This is a hold over from the dark past when we were running Altos systems that required one to be root in order to enable/disable ports. This was also years before HDB uucp as well. The theory of disabling a port to drop DTR so the modem stops answering the phone is great, as long as the modem is configured properly to follow the DTR signal. In a heavy support environment, where a modem can be pulled out of service and another substituted, I found that I could not rely on everyone to ensure that a modem was configured properly before putting it in service. We found modems occasionally answering the phone on business lines. Having a shell script determine if a particular port should be answering or not, based on time of day and weekend or not, was the best way to ensure that no caller was ever greeted with a screech in their ear. I still prefer it because I believe there is less that can go wrong, once the relationships between the files and the functionality of HDB is understood. :And my last piece of advice is that right-justification looks like :crap on crt's. Please leave it ragged right. I thank you, and my :astigmatismatic eyeballs thank you. Our newsreader brings up our word processor for editing and the default ruler is right justified. I am so used to seeing justified text that I never noticed that it was doing this for articles. You are the first one to ever mention this, but since CRTs aren't going to be displaying proportionally, there is no point in justifying. As you can see, I've changed my default setting. Thanks for the advice. I've saved your description of getty behavior for others who may be mystified. -- Bill Irwin - The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | Your Computer bill@twg.bc.ca (604) 430-4329 (fax) | Systems Partner
oli@odbffm.incom.de (Oliver Boehmer) (01/31/91)
In <578@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: >chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >:The moral of the story is if you are going to put a modem on the >:line - even if you aren't running uucp upon it - then make sure >:there is a good Devices entry. >I have come to the realization that the &hayes2400 entry in >Dialers was running whenever the port was enabled. By specifying >the hayes1200 dialer, which doesn't set S0, the problem is gone. wrong. The entry &hayes2400 is executed when the port is brought up to default state, after the connection is finished. uucp executed the hayes2400-line (w/o &) via uuchat prior to dialing. Afterwards, it executes the &hayes-line. oli -- --------------------------------------------------------------------- Oliver Boehmer, Frankfurt, Germany uucp: oli@odbffm.incom.de +49-69-331461 (voice) +49-60-308265 (12/2400) If God is perfect, why did He create discontinuous functions?
bill@twg.bc.ca (Bill Irwin) (02/04/91)
oli@odbffm.incom.de (Oliver Boehmer) writes: :In <578@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: :>I have come to the realization that the &hayes2400 entry in :>Dialers was running whenever the port was enabled. By specifying :>the hayes1200 dialer, which doesn't set S0, the problem is gone. :wrong. The entry &hayes2400 is executed when the port is brought up to :default state, after the connection is finished. uucp executed the :hayes2400-line (w/o &) via uuchat prior to dialing. Afterwards, it executes :the &hayes-line. What you said is true. What I said is also true. When I had the line configured for the hayes2400 dialer, I simply disabled and enabled the port. This action turned the AA light back on. It seems that whenever another process is finished with the port , or the port is enabled, the uugetty runs uuchat which looks for an "&" version of the dialer entry. :Oliver Boehmer, Frankfurt, Germany uucp: oli@odbffm.incom.de -- Bill Irwin - The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | Your Computer bill@twg.bc.ca (604) 430-4329 (fax) | Systems Partner