Re: BACKUP causing alpha node to crash

In article <45adfd2f$0$8780$c3e8da3@xxxxxxxxxxxxxxxxx>, JF Mezei
<jfmezei.spamnot@xxxxxxxxxxxxx> wrote:

Peter 'EPLAN' LANGSTOEGER wrote:
VMS83A_ADDENDUM V2.0 is already replaced too.

Thanks for the warning. I am really not up to speed with the not-so-obvious
nomenclature and hiearchy of patch names. They really should begin with a
sequential number indicating the overall order in which they were issued,
followed by whatever text they want.

If you read the friendly documentation for PCSI, you'll find that the
fields in the name are somewhat rigidly defined. The only way to make the
kits "sequential" as you suggest would be to give all the patch kits for a
release the same name, and just increment the version field.
VMS83A_PATCH-V0100, VMS83A_PATCH-V0200, etc.

I don't think many people would find that naming scheme an improvement.

Right now, there is no way to know that VMS83A_UPDATE-V0100 was issued
after VMS83A_ADDENDUM-V0200 just by looking at the names.

That's what the release notes are for. You don't really want the whole
release notes encoded into the patch name, do you?

If reading the
master ECO text is a requirement, perhaps they should add a file that is
automatically displayed when one CDs into that directory.

Dunno what you mean by "master ECO text".

You should definitely consider the release notes required reading before
you install a patch.

Naming conventions for VMS patches have evolved a bit over the years, but
here are some guidelines...

1. When patches have the same name (e.g. V83A_ADDENDUM), the one with the
highest version supersedes all the others. The content is cumulative.
You would rarely, if ever, need to install V0100 and V0200. If V0200 is
shipping, V0100 is redundant.

2. Many patch names are picked to show the main area of functionality.
BACKUP, LAN, RMS, etc. follow this pattern.

3. SYS kits are usually something to do with the OS kernel. More
precisely, they usually contain stuff from the [SYS...] facility within
the VMS build. Functionally, they can affect almost anything. My advice
is to ALWAYS read the release notes for any new SYS kit that comes out.

4. UPDATE kits have been used for quite a few releases now. Generally,
there is NO new content in UPDATE kits; they are just bundles of existing
patches. UPDATE kits are made specifically to reduce the work of
installing individual patches.

Generally all customers should install UPDATE kits. UPDATE kits will
usually be prequisites for most patch kits that come later.

UPDATE kits usually get an extended test cycle, so when they are issued
there may be a few very recent individual patches that are NOT included in
the UPDATE.

5. I think ADDENDUM kits are a recent (V8.3?) addition to the lineup.
These are basically "stuff that didn't make it in time for the release",
or "stuff that didn't make it in time for the previous ADDENDUM kit".
Alas, occasionally there is "stuff to fix stuff in the previous ADDENDUM
kit".


The recent VMS Integrity releases have all included new functionality
that's difficult to deliver in patch kits. Often this is support for new
systems, which are coming faster than the traditional Alphaserver pace.
Sometimes the new functionality is deeply-buried changes in the kernel.

This new functionality often comes with its own schedule, not related to
VMS and not under the control of VMS engineering. And this is often
high-priority functionality, mainly customers clamoring for support for
new system families.

At the same time, VMS engineering has finite capacity. The comfort level
is somewhere between 1 and 2 VMS releases in the pipeline at once. And
customers have been saying VMS releases should be a bit farther apart;
anything less than about 18 months seems to be too often.

Taken together, these considerations mean that VMS releases have recently
had, and will likely continue to have, randomly-changing, hardware-driven,
must-ship dates. New functionality that isn't quite ready will tend to be
ejected from the main release and moved into something like an ADDENDUM
kit.

Alternatives would be shipping stuff that's not ready (which unfortunately
sometimes happens by accident), or holding back the ADDENDUM stuff until
the next release. There are good arguments for rejecting both of these
alternatives.


Feedback about VMS policies for patch kits and releases can always be sent
to VMS management. (I would not expect them to wade though the noise here
in c.o.v. and notice feedback and suggestions.)

Feedback about the ITRC patch delivery process should go to ITRC. There's
no harm in copying the VMS patch release folks for relevant topics.

I hope some of this information is useful to somebody.
.

Relevant Pages