kevin@msa3b.UUCP (Kevin P. Kleinfelter) (01/28/91)
robin@batcomp.austin.ibm.com (Robin D. Wilson) writes: >In article <1498@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: ... >>In the course of diagnosing the problem, we discovered that "pdisable -a" >>did NOT drop DTR to the modems... SOMETIMES. We did not have HUPCL >>in LOGMODES for the port, but we did have it for RUNMODES. If someone >>had not logged-in on a port, pdisabling the port did not drop DTR. >> >>In other words, if HUPCL is not set (i.e. "stty -hupcl"), then >>pdisableing a port does not drop DTR. I assert that this is a bug. >>True or false? >Basically, when you set "-hupcl" on a tty, you are telling it, "No matter >what else I say, don't drop DTR. (ie. don't hang up and close this port.)" >So no, this is not a bug. The way around this problem is to add HUPCL to the >"STTY attributes at LOGIN" in SMIT. (BTW, this will become the default at some >point in the future.) Consider the following: HUPCL is set in LOGMODES and RUNMODES for the port; A user logs-in and executes "stty -hupcl"; Now, "pdisable -a" does NOT drop DTR on his modem. My assertion is NOT that HUPCL does not work -- my assertion is that pdisable should do whatever is necessary to "disable" the port, and that a "disabled port" should have DTR low, because the "data terminal" is NOT ready. The actions of a USER should not impact the effect of pdisable by an ADMINISTRATOR. If pdisable does not drop dtr, then how is the system administrator to disable all logins and drop all DTR? The following will NOT work: for x in 1 2 3 4 5 6 7 8 do stty hupcl < /dev/tty$x pdisable $x done because the port may have "-clocal" set and have CD low, causing the stty to hang. Simply put, pdisable should override hupcl, and not vice versa. -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 {emory,gatech}!nanovx!msa3b!kevin Look closely at the return address. It is nanovx and NOT nanovAx.
robin@batcomp.austin.ibm.com (Robin D. Wilson) (01/31/91)
In article <1510@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >Consider the following: > HUPCL is set in LOGMODES and RUNMODES for the port; > A user logs-in and executes "stty -hupcl"; >Now, "pdisable -a" does NOT drop DTR on his modem. My assertion is NOT >that HUPCL does not work -- my assertion is that pdisable should do whatever >is necessary to "disable" the port, and that a "disabled port" should have >DTR low, because the "data terminal" is NOT ready. The actions of a USER >should not impact the effect of pdisable by an ADMINISTRATOR. The ONLY purpose of pdisable is to turn off the getty running on the port. It is not intended to change tty settings, or "disable" usage of a port... Only to disable the "getty" process on that port. When pdisable is issue on a port that has set "stty -hupcl", it actually kills the process running on the port, and sets the inittab entry for that port to "off" instead of "respawn". The port can still be used for dial-out connections, or for other porgrams that any user has permission to start on the port. HOWEVER, if the user has set "-hupcl" the simple act of "closing" the port (via the "close()") system call, will not cause the device driver to drop DTR. That is the design. >If pdisable does not drop dtr, then how is the system administrator to >disable all logins and drop all DTR? The following will NOT work: > > for x in 1 2 3 4 5 6 7 8 > do > stty hupcl < /dev/tty$x > pdisable $x > done >because the port may have "-clocal" set and have CD low, causing the stty >to hang. To begin with, you don't have a problem if CD is low... (There is nobody logged in, so disabling the port will prevent new logins.) BUT.... If the attribute "hupcl" is set in the SMIT "stty attributes at LOGIN" then simply "penable" the port, and pdisable it again. This will reset the "-hupcl" to "hupcl" (and any other stty attributes the user might have set). BTW, it is crucial that the port be "PENABLE'd" and not PSTART'ed, PSHARE'd, or PDELAY'ed because share and delay should wait for a CD signal to reset the stty attributes but ENABLE should do it right away. -- +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: robin%aixserv@uunet.uu.net | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)823-3015 | +-----------------------------------------------------------------------------+