I'd like to try to summarize "best practices" when it comes to software release upgrades.
For perspective, most of the rest of the software world doesn't offer coexistence and fallback support, especially to the degree IBM does with its z/OS and z/OS-based products. It's quite fortunate and special that we have formal, tested, supported, dependable coexistence and fallback. So my first advice is to exploit that serious safety advantage to the fullest, i.e. to stay within IBM supported release combinations and to stay at least reasonably current in your deployed software releases insofar as possible. Moreover, there's no longer any Single Version Charge (SVC) constraints, so go right ahead and order the latest releases and get them into your "Development" environments promptly. In the hopefully rare cases when there's a deviation from the previous paragraph, you have two basic choices to move forward: 1. Plan and execute "back to back" (or even "back to back to back..."), stepwise release upgrades, staying within IBM's supported release combinations through each step. 2. Leap forward using fewer steps, as few as one "big" step. I have encountered a few cases when Path #1 simply wasn't feasible. Path #2 can be the best available choice, with all factors carefully weighed and considered. The farther back you are in release levels, the more likely Path #2 will be the best available path. If you choose Path #2, or if you at least need help determining the best path forward, then it's well worth enlisting some deep expertise -- talented people who specialize in "big jump" upgrades who know the likely risks and how to mitigate them. Thereafter, those same talented people likely could also help you stay at least reasonably current in your releases. You *can* move forward, and if you'd like some initial advice you can send me an e-mail if you'd like. As one story, I worked with a particular government agency that ran their mainframe for just over 18 years in productive, essential service with literally zero hardware, operating system, and middleware release upgrades -- not even a PTF installation. Yes, 18 years! Their operator console ran Windows 98, for example -- the original Windows 98, not Windows 98 Second Edition. :-) They recently upgraded to supported hardware and software, and the new environment works well and immediately delivered significant end user improvements. Everyone involved at least intends never to repeat that episode of extreme inertia, but even in that incredible case we found a reasonable way forward via Path #2. It turned out the single biggest technical challenge was to move data to the new mainframe reliably and quickly enough to fit within an "acceptable" (but still uncomfortable) planned outage window, but after a lot of research and effort that challenge was conquered. Please don't do what that agency did (er, didn't do), with the possible exception of a computer museum demonstration. Finally, if you don't have a Parallel Sysplex, please at least consider it. As a reminder, you can have (and it's quite common to have) a Parallel Sysplex on a single machine. You can decide how much or how little you want to exploit Parallel Sysplex, subsystem by subsystem. For example, if all you really urgently need is MQ shared queues so that you can keep receiving messages during a short interval when you're bouncing CICS, then start with that feature. If an IBM z/OS-based product supports Parallel Sysplex (most do), then that support is included already at no additional charge with your licenses. Parallel Sysplex is a wonderful, unique capability to manage and deliver upgrades without requiring service interruptions. It's another incredibly useful "safety net." Parallel Sysplex shouldn't be scary, but if it is for you at the moment, then reach out for help. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE -------------------------------------------------------------------------------------------------------- E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
