Thanks to all who responded
Alan Davis
Tom Webster
Dr. Thomas Blinn
The answers have been so detailed and showed so much effort
that I am hurrying to provide the summary just to avoid that
others from the list put also as much time on this issue.
My original request was: How to get a better overview and
more clarity about the Tru64 Unix upgrade policy.
All three answers gave me a better understanding with a lot
of details, therefore I include all of them in full length
here.
Thanks and regards
Otto
The answers:
Alan Davis:
-----------
Otto,
Tru64 doesn't have an "upgrade policy" that can be directly
(or sanely) tied to revision levels. There are times when
higher revisions are released before lower revisions, as is
the case with v5.0, v5.0a revisions being released before
v4.0g. It's most obvious at the end of one major revisions
life and the beginning of the next.
The v5.0x releases have major functional differences from the
v4.0x releases. This makes upgrades more complex, but
delivers more functionality.
The v4.0x releases are either minor feature enhancements, bug
fixes, or new hardware support.
Deciding what version to upgrade to depends on many factors,
some of which
are :
hardware requirements
does the latest version remove support for
hardware that I can't replace?
does the new hardware I'm getting require
the latest revision?
software requirement
does my software work with the latest
revision?
expertise available
do I want to learn the new revision now?
stability
can I wait until the latest version is
stable?
All your systems should be at least at v4.0d + patch kits,
for Y2K compliance reasons.
Updating to v4.0g when it comes out is relatively painless,
no software re-qualification is usually required.
Installing v5.0 is a major upgrade and, in some ways,
drastically changes the system. There is information
available on the differences in the release notes.
Alan Davis
Tom Webster:
------------
Otto,
> Here on the list I see requests for V4.0G, problems with V4.0F. On the
> other hand I know that V5.0 is out - at least I have a distribution.
> From VMS I know if a new major release comes out there are no more
> upgrades for the older versions (except may be maintenance releases for
> particular hardware). Therefore the natural way is then to proceed to
> this newer major release (or if it is a .0 version which some people
> don't like to wait for the next .1 version)
This is my understanding of the way that releases are handled, based
on experience going back to OSF/1 3.2:
Major Releases: Big changes to the way the system works. You will
need to test your third party software to make sure it works correctly
on the new version. For whatever reason Compaq has been skipping the
point releases, presumably following Sun's lead in releasing what
used to be minor revisions as major releases.
Letter Changes: Adds relatively minor new features and support for
new hardware. Most if not all software will work between letter
changes with no issues.
Patch Kits: Bug fixes. Some new features may be incorporated if the
features are part of the the code base for a later release (which
does not have the problem).
NSD Kits (New Device Support): This is new with the 4.0x series and
is an attempt to add additional hardware support w/o requiring an
upgrade. Thus far, I've only seen it used for network card drivers.
For whatever reason, I've noticed the following:
As of revision D of the OS, the next major version has been announced
and will usually be out by the time that E or F is released.
The interim releases (E & F) generally contain flowed down code from
the next major release's code base to solve problems or improve
performance (if it can be integrated w/o causing problems). These
releases also add support for new hardware.
Release G (for the last two versions at least) is the terminal release.
It seems to be as stable as possible (more so than E & F). This
release appears to be the one for sites using third party software
that won't run on the new version (or your home grown software depends
on a version of third party software that won't run on the next
major release).
Odd notes about versions and patch kits (pure opinion):
X.X Usually good attempts, but not safe for production (server) use.
Load on testbed systems and beat them up. Bug reports help
you help Compaq help you.
X.X(a-b) Good general release for desktops, small servers, and well
tested server upgrades.
X.X(c-d) Usually good solid versions (unless they are hardware support
only releases (DU4.0c)). Safe for enterprise servers.
X.Xg The golden version, but also a dead-end.
PK1 The first patch kit seems to be mostly stuff that was caught
between the release of the code to manufacturing (to press
the disks) and release.
PK2 Problems found by early adopters, not addressed by PK1.
PK3 Problems found in general use.
PK4+ More problems and flow-down code from development of next
version.
If you are running an enterprise server, something like X.X[b|c] (PK3)
is where you would want to start. Of course, if everyone waits until
then -- no bugs will be found. People really need to be willing to
run early releases to see if they function correctly in their
environment. One of the nice things about Tru64 is that the same
code base runs on every system, unlike other commercial UNIX variants
that run different kernel code on workstations and servers. It lets
you test on workstations and departmental servers w/o needing a
spare 8400 for testing.
> My problem now is that I want to get all my systems on the same
> revision level. So I see different possibilities
> a) because the situation is quite unclear for me I will
> bring the rest of my systems to V4.0D (might be the savest
> solution)
> b) go with all systems to V5.0
> Because in every case I would do a complete reinstall ( in case a)
> for V4.0d or in b) for 5.0, because of my experience with these
> complicated incremental unix upgrades this seems to me the fastest way)
> the question for me is:
I'd tend to disagree, but then I mess about with the configuration
of my systems, so a full reinstall can be painful.
My suggestion would be to upgrade the bulk of your systems to 4.0D
or wait for 4.0G. Pick out a couple of workstations (and/or small
servers) and install 5.0A on them. 5.0 has some differences that
you should start getting used to before a major roll-out.
> What I am somewhat missing is a clear upgrade strategy in this
> tru-unix area. From VMS I am used that I get the information about
> upgrade pathes
> e.g. 5.5 - 6.1 - 6.2 - 7.0 -7.1 - 7.2
4.0 - 4.0a - 4.0b - 4.0c - 4.0d - 4.0e - 4.0f - 4.0g
| | | |
5.0 - 5.0a - 5.0b - 5.0c - 5.0d - 5.0f...
| |
6.0 - 6.0a...
The scheduling isn't that exact, but it is similar. That's not to
say that they may not decide to change the roadmap, but that's the
way it has been. You get several releases to decide if you can
migrate to the new version or lock yourself into an evolutionary
niche.
The upgrade matrix is what really confuses some people. If you get it
in your head to suddenly upgrade from 3.2g to 4.0a, you need to use the
following sequence:
3.2g - 4.0A* - 4.0B - 4.0D - 5.0 - 5.0A
* You could have gone to 4.0 and then to 4.0B, but it wouldn't
save you any trouble.
Since you plan on reloading the systems, you won't have to worry about
that. If you look at the upgrade matrix:
http://www.UNIX.digital.com/faqs/publications/base_doc/DOCUMENTATION/V50A_H
TML/ARH8SBTE/TITLE.HTM
You can get an idea of the manner in which development overlaps:
4.0B and 4.0C can't go to 5.0 directly. 4.0D and 4.0F can go to 5.0.
[4.0E was a hardware support version and needs to go to 4.0F before
doing anything else.] 4.0F can also go to 5.0A, due to the overlap.
> Sorry, may be I am too simple minded for the unix culture, I really
> like this list which is great and gives a lot of information But
> sometimes, just regarding this issue I even get more confused here...
> Now the question: What is the best URL (from Compaq) about the
> tru-unix upgrade policy?
I'm afraid that I don't know of one. The policy is confusing at
times, but it is better than other vendors who try to force you to
upgrade before you have time to get a version of your RDBMS that
works on the new OS (and your local developers have two months to
adjust to the new RDBMS).
Tom
+-----------------------------------+---------------------------------+
| Tom Webster | "Funny, I've never seen it |
| SysAdmin MDA-SSD ISS-IS-HB-S&O | do THAT before...." |
| webster_at_ssdpdc.lgb.cal.boeing.com | - Any user support person |
+-----------------------------------+---------------------------------+
| Unless clearly stated otherwise, all opinions are my own. |
+---------------------------------------------------------------------+
Dr. Thomas Blinn:
-----------------
You are right, the situation can be confusing, and I don't
think you'll find much clarity on ANY of Compaq's web pages.
Depending on your hardware, you may be able to run V4.0D on
every system, and if so, running V4.0D with the latest
patches is a good solution. V4.0D was the first Year 2000
compliant release. But it does NOT have support for any of
the EV6 based systems (added in V4.0E) or for FibreChannel
storage (first added in V4.0F). And, of course, it doesn't
support the GS160 systems (to be added in V4.0G). But it
WILL be supported (through "prior version support") for some
time to come, I believe at least until the end of 2001, and
there are MANY people running that version. (I'm running
that version the system where I am composing this reply.) If
you have any dependencies on Adobe's Display PostScript or
the applications (like dxmail) that use it, you are better
off running V4.0D than a later V4.0x release. If you have a
requirement to use the older "dx" applications or the "xdm"
desktop manager (instead of CDE), it is also a better release
than say V5.x (where only CDE is available and many of the
older "dx" applications as well as DPS are retired).
You do NOT want to go to V5.0. V5.0A has just shipped, and
it's MUCH better than V5.0 (and since you don't trust
installupdate, once you reinstall you'll be there for a long
time). If you don't need any of the features added into V5.0
or V5.0A, and your user base knows V4.0x and your operators
know V4.0x, I would strongly recommend either going to V4.0D
or waiting for V4.0G and then going to V4.0G on all systems.
Depending on your hardware mix (e.g., DEC 3000 systems with
3D graphics, or even with graphics at all) you may not have
support for all your hardware in V5.0 and later releases.
This will be less of a problem in V4.0G. If you have any of
the really old systems that don't have a PCI bus at all (such
as the DEC 3000, DEC 4000, DEC 7000, or DEC 2000 models or
the DECpc AXP/150), you may want to stick with V4.0x on them
forever anyway, since the support of these systems will be
retired at some point in the V5.x releases (probably in the
release after V5.1, and V5.1 will happen this summer).
Again, unless you NEED AND WANT the V5.x features right away,
and you really want the same release everywhere, go with
V4.0D (if it supports all of your hardware systems) or wait a
bit and move to V4.0G. Both V4.0D and V4.0G will be
supported for a LONG time to come (as such things go).
Tom
Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer
Corporation
Received on Sat May 13 2000 - 21:34:36 NZST