Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!uwmacc!uwmcsd1!lakesys!gryphon!ddsw1!karl
From: karl@ddsw1.UUCP (Karl Denninger)
Newsgroups: comp.unix.xenix
Subject: Re: Huh?
Message-ID: <133@ddsw1.UUCP>
Date: Sun, 5-Jul-87 01:35:55 EDT
Article-I.D.: ddsw1.133
Posted: Sun Jul  5 01:35:55 1987
Date-Received: Sun, 5-Jul-87 19:37:18 EDT
References: <143@lakesys.UUCP> <141@hobbes.UUCP>
Distribution: na
Organization: Macro Computer Solutions Inc., Mundelein IL
Lines: 107
Summary: But neither is Microport

In article <141@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes:
> +---- Steven Goodman writes the following in article <143@lakesys.UUCP> ----
> |              To be abit more accurate on the naming of Xenix one might call
> | it:  Xenix System V Release 2.
> 
> Does SVID address libraries?  Xenix (By IBM for the AT) has no terminfo
> (termcap instead), incompatable header files, and a non-System 5 compiling
> environment (ie, it is a mix of what someone thought was the best of BSD
> and the best of Sys5.  I could never be sure which system I was on.
> Makefiles which assumed either Sys5 or BSD didn't work correctly.  I used
> it for 6 months before giving up on it.  EVERY program I tried to compile
> needed modification - It wasn't quite System 5 and it wasn't quite BSD.  I
> de-installed Xenix and brought up Microport System5.  ALL the programs I
				   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> had problems with under Xenix now compiled cleanly!  (This was using the SAME
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> base source code)
> Please tell me that this is just in IBM's port of Xenix - then I won't 
> have this bad taste in my mouth forever!

I have been seeing these postings for several months -- and until we got
heavily into development work with Microport, I would have agreed with you.
However, our latest projects as well as our (finally successful) attempt to
establish a Usenet site on Microport have given me a better overall view of
the situation.

You've been misled by IBMs version. Let me tell you of some of the problems
we currently have with Microport SYSV (2.2.2, the latest):

1) Panics in the serial driver -- routine 'rmsd'. Looks a heck of a lot like
   recursion at the interrupt level, but without source, who knows?
   Microport told us for 4 months that it wasn't a bug in the code. Now they
   admit it's broken, but it's not on the top of their list. (Also dropped
   characters, which are a real pain especially with #3 below)

2) Brain-damage: Specifically, 'varargs' things don't always work the way 
   they should, or dump core.  Also, what is this about not being able to 
   use indirection in large model to get around segmentation problems? 
   (As in 'array of pointers cannot point to >64k of data' -- known bug, 
   #329, V1.3, verified). 1.3 was here in December -- and it's still not 
   fixed! Also, the memory allocation routines have problems, if used often 
   enough in a program you can get a nice core dump from them as well 
   (free list corruption perhaps??)

3) UUCP -- sorry again. It's not reliable over packet-switched networks.
   In particular, Telenet barfs it quite often --- and it seems to
   lose an inordinate number of packets (which requires re-sync and
   retransmit). This could be related to the serial problems, but somehow I
   doubt it, as nothing ELSE has problems on the serial lines to this extent
   (we're talking about dropping packets consistantly and in large numbers
   -- failed transmissions, etc..) If you're thinking about feeding Usenet
   through this system you better hang on real tight! The deaths seem to be
   related to the length of time you are connected (it gets worse on long
   transmissions). Debug '-x[1-9]' to uucico will dump core if you are in the
   "MASTER" role and have nothing to send.  Finally, 'dialinfo' was kludged when
   it was integrated with uucico, so a Pc-Persuit dialer was out of the
   question (unless you are willing to dedicate a speed class to it -- like
   1200. Full details on this to anyone who asks - it's long).

4) Panics in the floating point -- first a divide by zero exception w/80287
   would crash the system. Then a floating point emulator bug was found (for
   those without 80287) that would kill it as well (but the circumstances
   were never documented by Microport).  6 months after I first saw the
   80287 divide-by-zero problem, it is not fixed.  The emulator bug wasn't
   fixed until 2.2.2.

5) Standard I/O (open for 'r+') is broken. This is documented, and in fact,
   from the news software it appears that AT&T broke it in SysV, but
   nonetheless it could be fixed.

6) They want to charge me to fix BUGS that panic my system! I don't mind
   paying for enhancements. Bug fixes are another matter, especially when I
   am told 'there is no problem' during my 90 day so-called warranty (as we
   were on the serial problems). Now we get hit everytime they ship an
   update, and the last time was a waste of my time and money to install. It
   fixed nothing, and may have broken some things (we're not sure about the
   breaking yet, but are in the middle of running some checks).

You may have been able to COMPILE things cleanly, but how many of them ran?
news 2.11, smail, and many others have run here -- but not out of the wrapper.
Things like 'pathalias' still don't run -- and although I have a working
version for Xenix V, I *cannot* make that same version run on Microport (bug
#2 above). It's usually stupid stuff, but once in a while you really hit a 
wall -- like when the 'varargs' problem bites you. The pointer problem makes 
things fun too.

How often does your system hang or panic under Microport? We crash here
about once every 2-3 days in the SIO code. I simply *cannot* sell a system
to a client that has such a reproducable, documented problem. (Hook 2
Microport boxes together sometime at 9600 baud and see 1) how many characters
you lose and 2) how long it takes to panic the system. Uucp transfers work
real well for this). The only solution? A $1k smart serial board (with a
driver to REPLACE the junk currently in the kernel)

It's true that Xenix is not Unix SYSV -- but heck, with the problems I have
with SYSV, sometimes I am happy it's not the same. 

Do others have problems with SCO Xenix these days? I'd love to hear from 
people using either Microport or SCO that have opinions, bug reports, etc... 
Of course, I will summarize responses to the net if it appears there is 
sufficient interest.

-- 

Karl Denninger				UUCP : ...ihnp4!ddsw1!karl
Macro Computer Solutions		Dial : +1 (312) 566-8909 (300-1200)
"Quality solutions at a fair price"	Voice: +1 (312) 566-8910 (24 hrs)