Test SCO Xenix IPC reliability

[Greg Woods]

In article <5872 at rpp386.UUCP> jfh at rpp386.UUCP (The Beach Bum) writes:
> In article <5867 at rpp386.UUCP> jfh at rpp386.UUCP (The Beach Bum) writes:
> >the new version uses message queues and screams like a banshee.  that
> >should be final proof as to how bullet proof the message queues are
> >under xenix.
> 
> and here it is.  i actually developed this on pigs, a 68020 vme bus
> machine.  the code compiled first time out on rpp386.  portable, no?

I'll ignore that remark...

> for a really good work out, run this on the console.  if you want
> to prove there are NO bugs in the message passing code (despite
     ?????
> what certain SCO bashers will say) run this in the background with
Like ME for instance????
> a real high nice for a few days.  a bug fixed version of the shared
> memory tester could also be run to further bebunk the sco nay-sayers.
> what the heck, run them both in the background with a nice of say,
> plus 20, for a couple of days.  that should find any kinks.

How about running it for a couple of weeks, with no nice factor, along
with a shm and a sem tester, in multiple incarnations.  Meanwhile, do
a WHOLE lot of disk and tty I/O.  In other words, push it to the limit.
Make the machine so slow as to be un-usable for anything else.

Come on guys.  Even the support people at SCO came up with a better test
programme, and still had no luck finding any bugs.  It works, but if you
work it too hard, it'll drop.  Now I know better:  don't try to do
something with the wrong tools.

I have no doubt Xenix is a nice little implementation of Unix for those
who can't justify non-PC hardware (all too many in these days of < $1000
clones), and who can't decide if they like SysIII, SysV, V7, or BSD.  A
nice little hack that gives you a little of each, but the best of none.
Mind you, I would rather have it than MS-DOS or OS/2.  [ and you'll note
I don't put a smiley after this sentence ]  I should also say that the
SCO support people do try, and care about the quality of their product.
It's just that they had a lot to do to make up for a poor start, and
they are working on the most unforgiving hardware in common use.
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada