Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!apollo!mishkin
From: mishkin@apollo.COM (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: SR10.1, UUCP and getty problem
Message-ID: <41dcca60.18fa1@apollo.COM>
Date: 6 Mar 89 14:50:00 GMT
References: <2054@daimi.dk>
Reply-To: mishkin@apollo.com (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 31

In article <2054@daimi.dk> jnp@daimi.dk (J|rgen N|rgaard) writes:
>The connection seems to be working as long as we do polling of other
>systems (actually only one at the moment). But when we try to accept
>calls from other systems by running getty on the port to which the modem
>is connected the outward connection stops working. Using 'ps' it seems
>that as soon as the modem it sends a "carrier detect" to the port
>this (erroneously) is taking by getty and NOT the calling uucico.

Unfortunately, you can't (at least with the standard "getty" and "uucico")
use the same modem for both dial-in and dial-out.  (This case is a little
tricky and is something that I've seen not work on other systems as well.)
If you have a pretty simple environment (e.g. one modem), you can be a little
tricky in the way you invoke "uucico" -- basically, you write a shell script
that:

    (1) Does a "ps" to find the "getty" process
    (2) Suspends it ("kill -SUSP xxx")
    (3) Invokes "uucico"
    (4) Kills the "getty" process ("init" will start a fresh one).

If you have more than one modem that "uucico" might pick for a dialout
session, this scheme won't work because you won't know which "getty"
to shoot.

Hopefully (i.e. don't construe this as a promise) we'll eventually be
able to ship a "getty" that "cooperates" with "uucico" better (the
so-called "uugetty").
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       mishkin@apollo.com