Very Computer

In  Essential System Administration, Eileen Frisch discusses the
deficiency of many Unix implementations to handle the same modem to be
used to dialin and dialout.  Is this a problem with SCO OpenServer?

Thanks,

Eileen

Eileen Hilburn bruited (on 21Jul):
| In  Essential System Administration, Eileen Frisch discusses the
| deficiency of many Unix implementations to handle the same modem to be
| used to dialin and dialout.  Is this a problem with SCO OpenServer?

I don't know that book; what does Miss Frisch claim as deficiencies?

I've been using all modem ports (whether COM1/COM2 or ports on
intelligent serial boards) for both dial-in and dial-out under SCO
Xenix, SCO Unix 3.2v4.x, and SCO OpenServer 3.2v5.0.x, and it has
always seemed to me to be a perfectly normal and natural thing to do.

--

Not if you get all your ducks in a row. If you are using the PC COM1 and
COM2 ports, you enable the UPPER CASE device names for dialin, make sure
you have the right entries in /usr/lib/uucp/Devices, and in
/etc/inittab.

Skip one detail, and it will haunt you forever.

Or, if you use Autolog, you can let it put your ducks in a row when you
install Autolog.

http://www.softm.com/wscoaut.htm

Bob Rubendunst,
Soft Machines

Quote:>In  Essential System Administration, Eileen Frisch discusses the
>deficiency of many Unix implementations to handle the same modem to be
>used to dialin and dialout.  Is this a problem with SCO OpenServer?

Perhaps she needs to update the book.   That problem went away for
most OSes before the 1990s.  In the early/mid 1980s it was more of a
problem.  The first one I saw that got it right was on the
AT&T SysV R.2 - about 1986, on the 3B2 series.

I don't recall the last OS that I've worked on that couldn't handle
bi-directional communications, but I've been using bi-di since
1986.

$In  Essential System Administration, Eileen Frisch discusses the
$deficiency of many Unix implementations to handle the same modem to be
$used to dialin and dialout.  Is this a problem with SCO OpenServer?

   I haven't seen the text you mention, so I don't know the details
of this deficiency.

   From several years' experience, I can say that I've had pretty
good success at getting dialin/dialout modems working on SCO Xenix
(2.3.3 and above) and SCO Unix (3.2v2.0 up to OSR5.0.4).

   SCO systems have an enhancement which is not found on some other
Unix systems, which will help make them behave better with
shared dialin/dialout modems.  You can, of course, send an init
string to the modem when you want to call out.  The enhancement
is that you can also send an init string to the modem whenever
Unix sets the port up to accept calls - when the system first
comes up, or after the port has been used (either by a dial-in
or dial-out session).  If you craft your init string properly,
it should be able to set the modem up correctly every time.
--

----------------------------------------------------------------------------
Senior Manager                                  United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7          (416) 750-7946 x251

Stephen M. Dunn bruited (on 26Jul):
|    SCO systems have an enhancement which is not found on some other
| Unix systems, which will help make them behave better with
| shared dialin/dialout modems.  You can, of course, send an init
| string to the modem when you want to call out.  The enhancement
| is that you can also send an init string to the modem whenever
| Unix sets the port up to accept calls - when the system first
| comes up, or after the port has been used (either by a dial-in
| or dial-out session).  If you craft your init string properly,
| it should be able to set the modem up correctly every time.

I do not see this as any sort of enhancment at all.  It's 1998 now, and
I've not seen a new modem which doesn't accept &D3, so who needs to keep
sending setup strings to a modem which will reset itself from NVRAM when
DTR has dropped.

Forget setup strings, folks. talk to the modem once with cu, xc,
kermit, ecu, whatever; set it up properly; save the settings, and after
that never send anything more than AT, or at worst, ATZ, as a reset
string.

--

I disagree about the use of &D3 and NVRAM.  I have users that all the time
"borrow" the modem from our Unix system to use temporarily somewhere else.
The use of the setup strings forces the modem back into the state that is
necessary for proper use on the Unix system.

Mark L. Wise bruited (on 27Jul):
| I disagree about the use of &D3 and NVRAM.  I have users that all the time
| "borrow" the modem from our Unix system to use temporarily somewhere else.
| The use of the setup strings forces the modem back into the state that is
| necessary for proper use on the Unix system.

Never assume.  I had assumed that once one wrote the
proper settings into NVRAM, one would leave the modem
alone and never disconnect it.

Given the scene you paint, then of course one can't
rely on what's in NVRAM.  

--