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!