[mod.computers.vax] s/w upgrades in mid-term

A105@UWOCC1.BITNET (Brent Sterner) (09/02/86)

   This is for edu sites.  It is customary here to batch our s/w upgrades
at the end of term.  For VMS, is this really necessary?  The reason I ask
is that we have 6 DEC languages, and the volume by term-end can be fairly
large.  We also have some non-DEC products to be considered.  Do any of
your sites attempt any upgrades in mid-term?
   This mostly applies to maintenance releases.  I'd never upgrade VMS to
say 4.4 except in a slow period.  Am I being too cautious here as well?

Brent Sterner
Computing & Communications Services
Natural Sciences Building
The University of Western Ontario
London, Ontario, Canada
N6A 5B7
Telephone (519)661-2151 x6036
Network   <A105@UWOCC1.BITNET>

McGuire_Ed@GRINNELL.MAILNET (09/03/86)

>Date:         Tue, 2 Sep 1986 11:08 EDT
>From:           Brent Sterner  <A105%UWOCC1.BITNET@WISCVM.WISC.EDU>
>Subject:      s/w upgrades in mid-term (edu site)
>To: INFO-VAX-SUBMIT <info-vax@sri-KL.ARPA>
>
>   This is for edu sites.  It is customary here to batch our s/w upgrades
>at the end of term.  For VMS, is this really necessary?  The reason I ask
>is that we have 6 DEC languages, and the volume by term-end can be fairly
>large.  We also have some non-DEC products to be considered.  Do any of
>your sites attempt any upgrades in mid-term?
>   This mostly applies to maintenance releases.  I'd never upgrade VMS to
>say 4.4 except in a slow period.  Am I being too cautious here as well?

This is a subjective question, and the answer for each individual update is
different.  There are reasons to be cautious, and also reasons to go ahead and
boldly install that software update.  I can think of four important pros and
cons to updating software.  Only one of them is not directly related to the
user's environment.

Pro:
-  Users need new features or bug fixes contained in update
-  Vendor maintenance contract requires installation

Con:
-  Changes in software behavior require user retraining
-  Updates may introduce new bugs, requiring user retraining

Perhaps other people can suggest other important reasons.  The challenge is to
weigh these pros and cons and manipulate the user environment in a way that
does not frustrate the user.  This is the key: the users are what the system is
all about.

These are some observations of what we usually do and how we justify it, not
hard and fast guidelines.  You need the freedom to make a decision on each
individual update.

I routinely install maintenance updates to layered products anytime during the
year, with two weeks advance notice to the users, including a description of
any non-transparent changes.  This prevents updates from piling up.  And, these
updates typically have zero impact on the user.  This turns out to be a less
conservative approach than yours, and I justify it in terms of expediency: it
gets the bug fixes in sooner, and keeps the software at the vendor required
update level.

I might install major updates to layered products with two weeks' notice or put
them off until recess or summer break, depending on compatibility with the
previous version.  The update may not affect the user at all, or it may require
us to retrain everyone.  The decision is usually made by the computing group
that supports the product.

Maintenance updates to VMS are generally installed over a recess period, rather
than during classes.  An operating system update typically requires down time
and introduces more non-transparent changes than we are willing to impose upon
users without plenty of warning.  We are generally not waiting hungrily for
that neat new feature of the operating system or a critical bug fix (we would
not be running the current system if it didn't work).

Major updates to VMS (V4!) wait for summer break.  They always require plenty
of preparation.  Retraining is the deciding factore here.  We need the extra
time to relearn, look for bugs, change local documentation and workshop
outlines, etc.

By the way, I generally install layered product updates with the system
running, meaning no down time for users of other products.  This is another
reason I can justify installing them while school is in session.  Also, I tend
to wait a few weeks and check with DSIN or TSC before installing an update.