Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.sys.pyramid
Subject: Re: 90x upgrades
Message-ID: <228@athos.rutgers.edu>
Date: Mon, 16-Nov-87 04:05:32 EST
Article-I.D.: athos.228
Posted: Mon Nov 16 04:05:32 1987
Date-Received: Tue, 17-Nov-87 03:59:11 EST
References: <516@udiego.UUCP> <4395@caip.rutgers.edu> <3676@pwcs.StPaul.GOV>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 48

My overall comment about upgrades is that any major change in a system
(any system, not just Pyramids) is a possible source of problems, but
that with proper planning things can usually be made to work with
minimal hassle.  My impression from some of the notes here is that
some of the problems have been caused by trying to do too much at
once.  In particular, I'd avoid doing a hardware upgrade at the same
time as a major OS change.  I think my inclination would be to get the
software up to date first.  It should be possible to run the identical
kernel on your old and new systems, if it is configured to include all
the devices that are present on both.  I believe this is even true for
a change from a single processor to a multiprocessor system.  I
haven't tried this recently, but I believe you just get warning
messages at startup.  Of course running the wrong kernel is
inefficient, but it is still useful as a debugging tool.  (Running a
multi-processor kernel on a single-processor system wastes a few
percent of the CPU doing semaphore instructions that your
configuration doesn't need.)  Major OS changes have been nightmares on
our VMS systems also.  In general Pyramid upgrades have been no worse
than VMS or Sun.  Obviously things are much worse if you are badly out
of date.  As for the reliability you can expect, 3.1 was sort of a low
point for Pyramid.  The most reliable release we saw until recently
was 2.4.  It was not released, and 3.0 was rushed out the door order
to get the first multi-processor systems (90Mx) working.  3.1 was also
rushed.  By 4.0 things had started to recover.  The later PTF levels
of 4.0 are quite reasonable.  (The actual 4.0 release had some serious
network problems, so we found it unusable.)  I believe 4.1 is going to
be at least as good as 2.4.

Once you get your software up to date, then you can do the hardware
upgrade.  Most of the major upgrades might as well be buying a new
machine, so you should expect that there is going to be a problem or
two.  Not necessarily, but any big machine has enough parts that
trouble is a possibility.  This means not doing it during the time
when you are doing your final monthly payroll run, and at a time when
Pyramid field service is likely to be available for the next couple
of days to clean up any problems.

This all may sound like too much bother, but if you don't do periodic
upgrades, it's about as bad.  I mean, you can't run 2.1 forever.  If
you want until 6.0 is out because you are afraid of upgrades, you'll
have a much bigger problem than if you keep up with the software as it
is released (or soon thereafter - there is something to be said for
not putting up a new Pyramid release until there has been time for the
first few PTF's, though I hope that this will not be true of 6.1).
Similarly with the hardware.  You don't want to be the first person to
get a new model, unless you like being a pioneer, but falling behind
-- with any vendor -- has penalties that are at least as great, in
both performance and maintainability.