Bell Tech 386 SysVr3

Wed Aug 3 00:10:28 AEST 1988

In article <1988Jul30.141708.3175 at gpu.utcs.toronto.edu>, woods at gpu.utcs.toronto.edu (Greg Woods) writes:
> 
> Anyone who thinks Xenix is reliable has NEVER seen a truely reliable system.
> I worked with >10 Xenix 2.2.1 286 systems for a period 9 months.  At
> least one of them crashed every (working) day, and often they were up and
> down like yo-yo's.  Many of the crashes were due to kernel bugs.  Only a
> small percentage could be attributed to hardware or local software (ie.
> device drivers).  Many of the bugs are still un-found.

I don't understand what you are referring to.  We have sold, installed, and
support more Xenix systems than you have.  Over the past year our customers
have had a grand total of 3 crashes.  All of these crashes were on one computer
leading us to suspect hardware.  While the kernel may have bugs I have not
been impacted by them to a large extent.

> The Xenix serial driver cannot share interrupt vectors with more than
> one port.  It will lose data at 1200 baud.

I normally don't tell people that they don't know what they are talking
about, but you don't.  I have a number of systems which are hard-wired 
together using the normal TD,SD, GND wires on the RS232 line.  I have used
uucp, cu, pcomm, a local terminal program, and the ZMODEM protocal running
at 19200 baud.  The wires are unshielded, about 200 feet long, running in 
places next to ac power lines. As you know, the RS232 spec. is valid for
50 feet.  We have had NO DATA LOSS ON THESE LINES IN THE PAST 2 YEARS.  This
is using standard com1 and com2 ports.  At times we have boosted the speed to
38400 baud, and have had very few problems.  It is really nice to watch a 
5 megabyte file get transferred at these speeds.

Regarding the interrupt vectors, you are correct.  However, I would like to
know if the 386/ix product can share the interrupt vectors.  You don't say.

> 
> Interrupt driven ports ALWAYS take a lot of cpu.  Try a really smart
> board, such as Consensys PowerPorts.

Correct, but this statement is true for ANY unix, not just Xenix.

> 
> >| 1.  SCO may have the "look and feel" of UNIX, but it is not UNIX and is not
> >                                                    ^^^^^^^^^^^^^^
> >	This is just blatently untrue. Xenix is based on AT&T code. It's
> 
> Yeah, a mess of V7, SysIII, BSD4.0, and other junk; all hooked together
> by a buggy, non-standard, compiler.  As far as I know, they started the
> 2.x.x release with the AT&T 3B5 Sys V R2.1 tape.  However, I would guess

> Unfortunately, not all of the utilities were taken from that tape (ie. uucp).

Xenix has been available for several years now.  I didn't see any other 
versions of unix until about a year ago.  Microsoft wrote Xenix, then
licensed it to manufacturers for their own systems (Altos for example),
and then SCO got a deal to develope the commercial version.  Xenix has been
a reliable product now for a long time.  It has been ungoing improvement
for a long time.  It has features that the standard unix does not, (I am
not going to list them here).  A lot of these features have been included
to optimize the system for the end-user market.   While some portions of
Xenix are less than excellent (uucp as you mentioned), if you would read the
papers you would know that version 2.3 will be released on August 15.  Among
other things it will have HDB uucp, and binaries which run on AT&T Unix will
run on Xenix without recompiling.

> 
> The real problem is that SCO have built up a tremendous support
> reputation, and they are very wary of making any changes that may have
> dozens of users calling up.  Take for example the choice to make the
> user utilities display disk blocks as 512 byte units, even though the
> 2.x kernel uses 1024 byte blocks.  One support person hinted to me that
> they did not want to scare people who did a df, and found half their
> disk was suddenly gone!

Question for all you other unix gurus:  What systems which have the df command
report in 512 byte units, and what systems report is 1024 byte units?

Unix has been developed over the years, and the commands are a conglomeration
of many different people's ideas of what they wanted from the system.  Because
of this there is not a lot of sense in the way different utilities report
the same information.  SCO is doing the right thing in not changing the way
the standard commands report information.  If they did then many programs
and shell scripts will not work.  If you must complain about something 
complain about something worthwhile, not about standards and compatability.

> >	This is true, however virtual memory has been added, which is
> >	the most visible to most users.
> 
> I'd of thought it was invisible.  Boy, what a can of worms it is too!

Using the virtual memory I have had programs running on ten different screens
which needed a total of 6-8 meg of memory.  While the system was a little 
slow (I only have 2 meg, with 10 meg of swap space) everything worked.

> >compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of
> 
> This can be a very valuable selling point, but 386's (with VP/ix or
> Merge) make it moot.

How many one and two person shops need or can afford a good sized 386?  On
the other hand 286 machines are dirt cheap these days.  Xenix is a good
alternative to OS/2, and having the ability to develope on a 386 and then to
copy a binary to a 286 (I do it all the time) is extremely valuable and is
not a moot point.

> 
> >utilities and tools not in SVR3 and vice versa. To imply that the lacks
> 
> Such as?  From a developer's point of view (and in my opinion), SysVR3
					      ^^^^^^^^^^^^^^^^^^
> has more, newer, better, tools than any other version.

	While SysVR3 has newer tools, are they really "better"?  For those
of us using Xenix the tools available are (in my opinion) better.

> >Xenix/386 passes SVID with the exception of one fairly obscure system
> 
> Is it binary (ie COFF) compatible yet?  Will the 286 version ever be?
> Will there ever be a "SysVR4 compatible" Xenix 286?  [ I hope not! :-) ]

	As I mentioned above, version 2.3 will be binary compatible.  I
don't know about the 286. 

> 
> Except when it generates wrong code, or none at all.  I've ported over
> 20 Mb of source.  Microsoft have MANY problems with "register" and the
> 286 makes it almost impossible to get pointer expressions correct.

I've been able to compile (after setting the correct options) almost everything
that has come over the net, including (dare I say it) spacewars.  It all
worked.

> >  I admit that I tested V/386, 386/ix and Xenix/386 and bought Xenix. I
> >did it based on reliability of the products as of 11 months ago, and I
> >have seen that the later versions of Xenix are still solid.
> 
> I bought (as have my clients who could), and STRONGLY recommend, 386/ix.
> I STRONGLY recommend not touching Microsoft development tools with a 10
> foot pole.
> 

Funny, Microsoft seems to be doing well selling their compilers and other
system development tools.

Jonathan B. Bayer
Intelligent Software Products, Inc.
19 Virginia Ave.
Rockville Centre, NY   11570
uunet!ispi!jbayer