Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cuae2.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!mgnetp!hw3b!wnuxb!cuae2!heiby
From: heiby@cuae2.UUCP (Ron Heiby)
Newsgroups: net.micro.att
Subject: Re: Help needed with Penril auto-answer/auto-dial modems on 3b2
Message-ID: <353@cuae2.UUCP>
Date: Fri, 5-Jul-85 11:03:04 EDT
Article-I.D.: cuae2.353
Posted: Fri Jul  5 11:03:04 1985
Date-Received: Sat, 6-Jul-85 10:44:32 EDT
References: <729@pyuxqq.UUCP> <186@lzwi.UUCP>
Reply-To: heiby@cuae2.UUCP (Ron Heiby)
Organization: AT&T-IS, /app/eng, Lisle, IL
Lines: 22

In article <186@lzwi.UUCP> psc@lzwi.UUCP (Paul S. R. Chisholm) writes:
>If you specify bidirectional instead, uugetty is run on
>the line.  Uugetty not only knows how to step out of the way of
>outgoing calls, but is a little bit smarter about smart modems.

The two main things about uugetty that makes it different from ordinary
getty is that A) it conforms to the same locking protocol that cu and
uucico conform to, and B) it doesn't "wake up" until it receives a character
(like a CR).  This means that someone (or a uucico) login in must send
a character before they will see a "login:" prompt.  It also means that
if characters are sent from the modem when a local uucico has ended and
the line disconnects, uugetty will see that there are incoming characters
and no current lock on the line, so it will "wake up".  I believe that
this is why the uugetty is supposed to be specified with a 60 second
timeout and why the documentation recommends not trying to access that
port for at least 60 seconds.  The key words are, "little bit smarter."

Part of the above is conjecture, although I believe it to be substantially
correct.  In short, don't worry about it.
-- 
Ron Heiby	heiby@cuae2.UUCP	(via ihnp4)
AT&T-IS, /app/eng, Lisle, IL	(312) 810-6109