LongEx Mainframe Quarterly - February 2011
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 run. 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? SupportA 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. New FeaturesWith 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. MoneyOften 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. Time LaterThe 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 ManagersThe 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. |
