Path: utzoo!attcan!uunet!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.mail.uucp
Subject: Re: Bidirectional Modem Lines under SunOS 4.0.1
Message-ID: <6623@nuchat.UUCP>
Date: 19 Apr 89 07:42:41 GMT
References: <160@osc.COM> <743@key.COM> <2209@laidbak.UUCP> <1404@auspex.auspex.com> <3774@ficc.uu.net> <13570@ncoast.ORG>
Reply-To: steve@nuchat.UUCP (Steve Nuchia)
Organization: Houston Public Access
Lines: 32

In article <13570@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>As quoted from <3774@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva):
>| We do it this way on Xenix 3.5, because it's the only way to do it, and I'm
>| having to rewrite init to track this multiple-tty-name stuff and clear

This can also be done in getty; pretty easy there, just clear it
all before you try the open, then set the locks and whatever
else when the open returns.  When you find a lock set use
kill 0 to see if it's real or memorex.

>Uh, Peter, is SCO Xenix *really* so broken that O_NDELAY and/or CLOCAL don't
>work?  I've used them in Microsoft Xenix 3.x (untouched by SCO) and UNIX

>I've never understood why SCO uses the two-file kluge.

It can be a real bitch to add O_NDELAY to an open call for which
you do not have source.

Why you might not have source is an excersize best left to
another newsgroup.  I do not have source for my uucico, for
instance.  My vendor does, but chooses to ignore the fact that
they do.  I would ignore them except I'm poor and hate DOS.

The file-name "kludge" is a useful, understandable, managable
solution, and is at least as "right" as O_NDELAY.  Use of
minor device bits to control things, like for instance tape
density, that application programmers failed to include ioctls
or special open flags for goes back a long way.
-- 
Steve Nuchia	      South Coast Computing Services
uunet!nuchat!steve    POB 890952  Houston, Texas  77289
(713) 964 2462	      Consultation & Systems, Support for PD Software.