Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!chinacat!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.aix Subject: Re: modems under delay not dropping DTR on 3003 Message-ID: <19388@rpp386.cactus.org> Date: 15 Jun 91 04:45:41 GMT References: <7815@spdcc.SPDCC.COM> <1991Jun13.133648.6748@pensoft.uucp> <7868@spdcc.SPDCC.COM> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cat Grill and Sushi Bar, The Republic of Texas Lines: 61 X-Clever-Slogan: Please send money. I need another NRA Life Membership. In article <7868@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >pensoft!robin writes: >>As far a "DELAY" not being used for dial-ups, please stop spreading this >>nasty rumor. "DELAY" works fine with both dial-up and direct connect. > >You should state this more clearly in the guide you put out; the way I >interpreted it, the 'getty' program will do the wrong thing by locking >the port if 'delay' is set and a character is received. *Most* modems >these days will send characters at numerous points when carrier detect >is not present. This needs to be spelled out in any documentation on >the subject. Your document clearly implies that getty ignores carrier >detect in making the decision to lock the port, if 'delay' is selected. OK. This is getting a bit silly. The code that handles "delay" does so by waiting for open to return then waiting for a character to be read. After this happens it sets the lock. If the lock fails, the port is opened by another application. This is exactly what the code does, and I know this because I wrote it. It has nothing to do with "ignoring carrier detect". It sounds to me like the TTY device driver is letting the open succeed if a character is present, or else the modem is doing strange things with the signals. I did try various tricks with TTY's and modems while working on the code, and it does appear to work quite correctly. My leaning is towards a problem with the modem [ since the machine that supports AIXServe is a S/6000 and uses modems and we know it works ] >>You call 1-800-237-5511. I think you are wasting your time, this is not a >>software defect. Sorry. Robin, you do not speak for IBM. Quit pretending you speak for IBM. You are no longer a contractor working on Level 2 support. >It need not be a software defect in order to be a major hassle for me. >There are numerous line-control parameters which may not be set correctly, >and I have yet to learn any means of fixing the problem. Therefore there >*is* a problem with the software, the documentation, or (more likely) both. This is what you are supposed to need for delay to work - * Modem set so DCD follows real DCD * Cable which supports DCD * Port set to "Delay" * CLOCAL turned off You can simulate your modem working in the following manner. Take a dumbascii terminal and connect it to your machine. Set up the parameters as described. Turn off the terminal and then turn it on. Press the key _once_. You should get a login prompt. Login as any user. Make certain that CLOCAL is off and HUPCL is on. Turn off the terminal. From another terminal check that your login session has been killed off. Turn back on the dumbascii and don't do anything for a minute or three. Notice that you don't get a prompt. Press the key once and you will get a prompt. If it doesn't work pretty much as I've described, something is wrong. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn