NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/xenix/sco/2913

Internet Message Format | 1992-09-13 | 3.3 KB

Path: sparky!uunet!dtix!darwin.sura.net!wupost!gumby!destroyer!mudos!mju
From: [e-mail] (Marc Unangst)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
Message-ID: <[e-mail]>
Date: 13 Sep 92 02:58:40 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: The Programmer's Pit Stop, Ann Arbor MI
Lines: 52

In article <[e-mail]> [e-mail] (Keith Smith) writes:
>Hmm,  During my experience with over 20 Xenix-286 sites running apps
>from Uniplex Office Automation, to Open Systems accounting to Point of
>Sale over the last 5 years I can't recall 1 system lock-up.  Of course
>they were all running "shrink wrap" applications on standard hardware.

Right.  And the programmers knew they were writing for the 286's
strange architecture, so they could be careful to not do things like
assume sizeof(int) == sizeof(int *).  But people writing software for
other machines with a flat memory model (i.e., the VAX) frequently
*did* make assumptions like these -- assumptions that did not hold
true on the 286.

>is this:  If the 2400 baud modem was adequate why would they "need" a
>9600 baud modem, and why would you assume you could not use one?  It
>runs 9600 baud terminals OK, why not a modem?  With an intelligent I/O
>card you could even push a DTE rate Higher than 9600.

Terminals are different from modems.  (But I suppose you knew that.)
When you have a terminal connected to a serial port, most of the I/O
is in the output direction -- from the computer to the terminal.  By
contrast, with a modem most of the I/O is usually in the inupt
direction -- from the modem to the computer.  And this is where the
problem comes in; if you have a modem that is able to pump data at the
computer faster than the computer can handle it, you will have
problems.  These sort of problems don't crop up with terminals because
most of the time it's the computer doing the data-pumping, and you
just have to worry about making the terminal fast enough to handle the
data rate.

Why would they need a 9600bps modem?  Most of their modem use was for
remote tech support from their application vendor; if their vendor had
9600bps modems, they could reduce their long-distance bill by getting
a 9600bps modem.  It turned out that either their vendor didn't have
9600bps modems, or they didn't want to spend the money for a Telebit
T1600 or T3000 (which is what we would have sold them if they wanted a
9600bps or 14.4Kbps modem); I forget which.  But at any rate we didn't
sell them a high-speed modem, so we'll never know if it would have
been a problem.

>Oh,  BTW,  9 of the 286's above were running USR Dual Standards and the
>286's were 286/12's.  They were POS systems pushing a lot of transaction
>data to a home office at night via modem.

Well, that explains it then.  Most of the traffic was from the 286 to
the modem, instead of the other way 'round.  As long as you don't try
to pump data *into* the 286 at high speeds you won't have problems.

--
Marc Unangst                | Real men don't use Windows.  Real men use X.
[e-mail]   | Only a real man would use a GUI where the
                            | shift keys after "Alt" are "Super" and "Hyper."