Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!helps!uudell!pensoft!usenet
From: Robin D. Wilson
Newsgroups: comp.unix.aix
Subject: Re: modems under delay not dropping DTR on 3003
Message-ID: <1991Jun13.133648.6748@pensoft.uucp>
Date: 13 Jun 91 13:36:48 GMT
References: <7815@spdcc.SPDCC.COM>
Sender: usenet@pensoft.uucp (Usenet Psuedo User)
Reply-To: pensoft!robin
Organization: Pencom Software
Lines: 48

In article <7815@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes:
> 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.
>
> 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).

This is not true.  When "SHARE" is selected "getty" uses CD to determine when
to lock the port (as you suggest it should).  In fact, when the modem and the 
tty are correctly set-up, this works just fine (after applying the 3003  
update).  I have corresponded with Rich on this very subject and it appears to 
me that he is using a back level "patch" that he is applying over the update.
This is not a good thing to do.  (This is so far... PURE CONJECTURE ON MY  
PART.)  Anyway, it works fine for me after 3003 with Telebits, and Hayes.
 
> 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.

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.  DELAY does  
use CD to control when to read and write the port, but it does not use CD to  
determine when to lock the port.  DELAY waits to see a character on the serial  
input buffer before locking the port.  THIS WORKS AFTER 3003.  I have tried it  
with both direct connect serial connections, and modems.
 
> 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?

You call 1-800-237-5511.  I think you are wasting your time, this is not a  
software defect.     Sorry.
+-----------------------------------------------------------------------------+
|The views expressed herein, are the sole responsibility of the typist at hand|
+-----------------------------------------------------------------------------+
|UUCP:     pensoft!robin                                                      |
|USNail:   701 Canyon Bend Dr.                                                |
|          Pflugerville, TX  78660                                            |
|          Home: (512)251-6889      Work: (512)343-1111                       |
+-----------------------------------------------------------------------------+