opinion: Why Do We Keep Our Software Up to Date?
Take a look at a Systems Programmer's workload, and the chances are that
a large part will consist of upgrading systems software. But why do we always
upgrade this software, and is it really necessary?
It's a fact that for most mainframe systems administrators (or Systems Programmers),
the majority of their time and effort will be consumed by software upgrades.
It seems they're always working on a project to upgrade z/OS, CICS or some other
systems software. Many years ago, I had a manager who didn't see why this should
be, and stopped all software upgrades for a period of time. And you can see
his point. Upgrades consume a lot of time and effort. Upgrades have an element
of risk, and can cause disruptions and outages. Upgrades require training for
new functions and features. And upgrades on occasion can actually remove functionality.
This manager believed that keeping a stable environment was a better way to
And he is not alone. The Arcati 2010 survey indicated that 20% of z/OS users
at the time were running z/OS 1.8 or older: unsupported z/OS releases. So why
do we need to keep up to date with our software?
A good deal of the yearly cost of mainframe software goes towards the kind
of support that Windows users would die for. If there's a problem we report
it, and it gets solved. If the vendor needs to write a fix, they do. Otherwise,
they'll figure out what is wrong and help us fix it.
Software vendors simply can't support all the software they've ever written.
So they all have a policy of supporting only recent versions. For example IBM
support for z/OS extends back three releases. The current z/OS release is 1.12,
and the oldest supported release is 1.10.
But this doesn't mean that your vendor will drop you like a hot potato when
your software is out of support. However what it does mean is that the help
they will give you will be limited. You can expect no new software fixes, and
possibly less help with fixing other problems. More importantly, vendors will
not guarantee that unsupported software will work with anything else. For example,
ASG announced that its TMON monitor would support z/OS 1.12 from the first day
it was released. However this only extends to supported products. It won't make
any such guarantee for software out of support.
An interesting example was in 2000. Many mainframe sites were forced to upgrade
software to levels that were tagged as Year 2000 compliant by their vendors.
In many of these cases the old software would probably have worked fine, but
the vendors would not guarantee it.
Another example is hardware. IBM won't guarantee that unsupported software
will work with its new zEnterprise processors. It probably will, but again IBM
won't guarantee it.
So it makes sense to keep all software up to date so that it will work with
any new software or hardware. It's all but impossible to guarantee that a site
won't make any changes to hardware or software. Even computer hardware goes
out of support.
With every new software release comes new features and fixes. It's a no-brainer
that you get to enjoy these new features when you keep up-to-date. And in many
cases these new features are free.
Take the z/OS Health Checker. Fully functional in z/OS 1.10, it is a sensational
way to continually monitor your z/OS setup. And it comes free with z/OS.
However new features don't just happen. Like anything new, they need to be
identified, researched and implemented in a controlled way. Users need to be
notified and trained in relevant features, documentation updated, and operations
procedures changed. This is another project that needs to be done once the software
has been successfully upgraded. In some cases, Systems Programmers are too busy
upgrading software to actually implement new features.
Often new software provides performance improvements. For example, IBM suggests
that DB2 V10 can give a 5-10% performance improvement out-of-the-box, and up
to 20% for specific workloads. New compilers working with IBMs zEnterprise processor
can deliver up to 30% improvement in applications performance.
This performance can translate to delaying processor upgrades, and reduced
software costs. Or in other words, money.
Some vendors may also provide attractive software pricing structures to lure
customers onto new software.
The fact is that the older software is, the harder it is to bring it up to
date. IBM provides upgrade paths for all its supported software. But there is
no current upgrade path from z/OS 1.8 to 1.12. This doesn't mean that such an
upgrade can't happen, but it is going to be very hard.
So keeping up to date will ease any work later that forces software upgrades.
This is particularly relevant for ISV products. Some sites have up-to-date
IBM software, and out-of-support ISV software.
What This Means for Managers
The chances are that any z/OS system will undergo changes and upgrades on an
ongoing basis. The challenge is to do such upgrades in a planned, controlled
manner. Software upgrades take a considerable amount of work. Any potential
problems with the myriad of existing software (and hardware) needs to be identified
ahead of time and resolved. Any pre-requisite software upgrades must be completed.
After this, the software must be installed, customised, and fully tested before
being migrated into production. Once in, functional changes and enhancements
must be identified, planned and implemented. None of this is trivial.
Managers with an outsourced mainframe may feel that none of this is relevant,
but the very opposite is true. Outsourcers may not upgrade software unless it
is required in the outsourcing contract. Even then, there may be nothing pushing
outsourcers to implement new features and performance benefits. It's in the
interest of outsourced managers to keep track of software levels, and any enhancements
and benefits that may be had. Local Systems Programmers, or an independent consulting
firm such as Longpela Expertise, will be your best friend here.