Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!hsdndev!spdcc!rbraun
From: rbraun@spdcc.COM (Rich Braun)
Newsgroups: comp.unix.aix
Subject: Re: modems under delay not dropping DTR on 3003
Message-ID: <7815@spdcc.SPDCC.COM>
Date: 11 Jun 91 17:08:08 GMT
References: <1991Jun7.034510.4004@ugc.uucp>
Organization: Kronos Inc., Waltham, Mass.
Lines: 26

geoff@ugc.uucp (Geoff Coleman) writes:
>	The latest response from IBM (the problem report has been open for
>months) is to run the lines as share rather than delay but whenever I run the 
>lines as "share" they immediately get locked and you can't cu out on them.

I think you just plain lose, whether you're running 3.1.1, 3.1.3, or
3.1.5.  I've thus far gotten no resolution out of IBM on this topic,
though to their credit they've kept in contact with me fairly well.

The problem, as I see it, is that getty doesn't respect the Carrier Detect
signal if "share" is selected.  It should *not* assert the /etc/locks file
until Carrier Detect is present, but it does (and hence prevents cu
or uucp from sharing the line).

As I understand it, "delay" is not to be used for dialups.  It causes
the device driver to ignore Carrier Detect entirely, which means a session
can remain logged in indefinitely as you've reported (whether dial-in or
dial-out, as in your case).  The IBM doc doesn't say this explicitly
enough, IMHO.  The only suitable settings for dialups are "share" and
"enable", and "share" doesn't work.

I wish to file a formal, written bug report on this topic, now that IBM
has closed out the problem number I'd previously filed via phone/e-mail.
How do I go about this?

-rich