Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!oberon!sdcrdcf!csun!polyslo!dorourke
From: dorourke@polyslo.UUCP (David O'Rourke)
Newsgroups: comp.arch
Subject: Re: stack machines (Burroughs)
Keywords: RISC, real-time
Message-ID: <3237@polyslo.UUCP>
Date: 22 Jun 88 17:29:49 GMT
References: <1521@pt.cs.cmu.edu> <1532@pt.cs.cmu.edu> <476@pcrat.UUCP> <3215@polyslo.UUCP> <374@dlscg1.UUCP>
Reply-To: dorourke@polyslo.UUCP (David O'Rourke)
Organization: Cal Poly State University -- San Luis Obispo
Lines: 63

In article <374@dlscg1.UUCP> dlsc1032@dlscg1.UUCP (Alan Beal) writes:
>  While we are on the subject, how does Unisys compare to other vendors in the
>number of patches applied to its software releases?  Currently we are release

  I was personally dismayed at the instability of the MCP.  For a 20 year old
OS it really isn't all that bullet proof.  We had production machines that
would halt-load every day just to clean them selves up.  I don't know of
too many other OS's that get so messed up that they have to re-boot to clean
everything out.
  Judging from this I'd say Unisys A-Series MCP tends to have more bug fixes
that other equivilant OS's.  BUT I DON'T REALLY KNOW, THIS IS OPINION BASED
ON MY EXPERIENCE.

>3.6 and are up to the 9th patch cycle.  The problem with most of the patches
>is that they usually cause more problems than they fix; most of the time it
>seems that no one must have tested the patches.  It is such a problem that
>the so called Unisys experts never seem to be able to remember what things
>were changed at what release.  As standard operating procedure we always
>extensively test any new patch release before permanently installing it on
>the system.  And it always seems that we are returning back to earlier, less
>patched versions of the same MCP release.  It can become a nightmare.

  The major problem seems to be that by the time the bugs are found the 
programmers: A) Quit due to frustration with Unisys,  B) Moved to another
section, C) Moved to another project.   After the MCP group turns it's 
software in to Product Assurance they don't see it again for about 3 - 6
months, by that time they've moved onto something else.  Normally the
person fixing the bug isn't the one who wrote it.  This also demonstrates
the problem with the Mono-Lithic structure of MCP, a change in one area
of the program might have side effects in other areas.  Another problems
stems from what I mentioned in an early article, no body reuses code!!
Everyone writes it themselves, rather than triing to make central calls.
Well if a problem with one part of the Code in MCP then there is a VERY
VERY VERY high probability that there is some similar code in the MCP
somewhere that also needs to be fixed, but typically this isn't found until
after the release.  It seems to be a problem with the Software engineering
aspect of MCP rather than bad programming.  The arch. of MCP is forced on
newer programmers even though they know better, and it just continues to
grow unchecked.
   An internal estimate from a couple of people in my group that I used
to work for estimated that if you were to re-implement MCP, not add one
single feature, just freeze it and rewrite it from scratch with today's
software techniques then they could probably get it down to about 300-400
thousand lines, Almost a 50% code reduction, and it would be MUCH MUCH more
extensible and easier to maintain, the problem is they estimated the project
to take 50-60 man years.  And Management didn't seem to like the idea of
spending all of those resources just get what the "already" have.  I
personally think it needs to be done or else the monster of MCP is going
to eat the A-Series people Alive.  Things are already grinding to a slow
crawl when any new feature is added to MCP, this will soon become almost
inifinate in the amount of resources required to make even the slightest
change.

   Thankyou for your comments.  This has been an interesting discussion.
I've learned a lot and I hope some people have found my comments useful.
I'm willing to continue it, but I've also been requested to move it to
another group.  Perhaps someone could recommend a group if they want
to continue this discussion.

-- 
David M. O'Rourke

Disclaimer: I don't represent the school.  All opinions are mine!