Microport Unix -- Large Model Problems

[tony mason]

In article <188 at vsedev.VSE.COM> ron at vsedev.VSE.COM (Ron Flax) writes:
>One other unrelated problem I have with Microport  Unix is  that for one
>reason or  another  the system  seems to  run for  a while  then when it
>decides its had enough it just  plain goes  south.   It appears  to be a
>deadlock situation  since  terminals  that  had  active  sessions  going
>continue to echo keystroke even  though it  doesn't respond  to them and
>non-active sessions (ie.  getty's running) do NOT echo keystrokes.  This
>obviously quite annoying as you might imagine...   One  other thing that
>is interesting is that I  know of  two other  sites with  the exact same
>problem on  different  hardware,  but  Microport claims  they have never
>heard of it?  Has anyone else  seen this  behavior?   Incidentally I was
>running SCO Xenix  V successfully  for about  6 months  prior to getting
>Microport Unix.  Microport are you listening 8-)
>

While running with SCO Xenix V all spring, we found that it would
periodically do EXACTLY what you are describing.  It made no difference what
machine we used (IBM AT, SPERRY IT, even ALTOS 2086)  it would die.  After
much in-depth research, and discussion with SCO's technical support
(overworked, harried people it often took a week just to get to talk to) it
turns out that it isn't too hard to get this problem to occur - just write a
large model program on the 80286 that uses sbrk() (and is returning large
pointers) and doesn't de-allocate at the end of the program (after all, why
do that?  The system takes care of it right?) this will lead to death.
Symptoms are:

	1. Terminals still echo characters
	2. Disk activity periodically (sync?)
	3. NOTHING can be done (except a reset) to get it back.

This is the infamous LARGE MODEL DEATH.  I was told by SCO that they had no
fix for it, and that their technical engineers were stumped (something like,
five of the last five "fixes" in house had failed to work.)

Naturally, we tested this out on other machines, and yes, it occurs on them
all.  (This was disasterous because the product was using INFORMIX - which
did have some large model pieces).

Perhaps this is what you are experiencing (if not, it is an AMAZING
coincidence).