YAASPP NOT Solved?

[Kevin P. Kleinfelter]

robin at batcomp.austin.ibm.com (Robin D. Wilson) writes:

>In article <1498 at msa3b.UUCP> kevin at 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.