Help! New owner of xenix need professional help!

[Jack F. Vogel]

In article <473 at fallst.UUCP> tkevans at fallst.UUCP (Tim Evans) writes:
>In article <3700008 at eecs.nwu.edu>, skrenta at eecs.nwu.edu (Richard Skrenta) writes:
>> So far I haven't found any reasonable way to use a modem both as dial in and
>> dial out.
>
>Version 2.2 (and, I assume, later ones as well) provide for bi-directional
>use of the same com port.  It's well explained in the UUCP section of the
>(I think) _User Guide_.  Basically, 'uucico' and 'cu' are smart enough
>(when a port is "enabled" for login) to kill the getty and "disable" the
>port whenever dialing out is initiated; getty is restarted once the call
>is completed.  Works great.

This is not strictly correct, uucico or cu do not "kill" the getty, if they
did that init would be signaled and respawn a new one. If you check during
the uucp use of the port (i.e.,run a ps) you will see the getty is still
a running process, that also means that the port is not "disabled". What
really happens is roughly this: both cu and uucico use a common dialer, in
that dialer a child is forked and ungetty is execed. ungetty first checks to
see if the port is enable, that is if a getty is running on it. If so it
sends a signal to the getty. Now SCO has a special getty with some signal
trapping routines in them, if it receives a SIGUSR1 it will then record the
fact that DIALOUT is using the port and wait on another signal. When uucp
has finished with the port getty will exit and init spawns a new one. NOTE
I say this is "roughly" how it works since I have not seen their code, I
have gleaned this much through tests with alternate getty code interacting
with ungetty. Also this scenario applies to 2.2.X, I believe with 2.3.X 
there is a new procedure. If someone from SCO cares to clarify further
or correct my analysis I would certainly be interested.

-- 
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack 
Internet: jack at turnkey.TCC.COM