Admin Alert: Planning An i 6.1 Upgrade

Published: April 18, 2012

by Joe Hertvik

As of this writing, my staff and I are preparing to upgrade the first of three System i 550 partitions from i5/OS V5R4 to i 6.1 on April 14. In an earlier article, I discussed getting started with a 6.1 upgrade. As a case study, this issue I'll go over the planning process for actually performing the upgrade by reviewing my planning process for an actual IBM i partition.

Completing The Pre-Upgrade Tasks

At this point, we've completed most of the heavy lifting needed to perform the upgrade. With our Applications group, we've gone through and corrected all system objects so that they can be properly converted after the upgrade. We've performed pre-upgrade processing and loaded all the operating system CDs and group and cumulative PTFs to an image catalog so we can more quickly run the upgrade and PTF procedures. We've surveyed all our vendors and performed any third-party software upgrades so that they will run on i 6.1. And all relevant parties have studied the System i i5/OS Memo to Users, Version 6, Release 1 (May 2011 update).

Like everyone else, we will be following the very clear and effective 6.1 upgrade steps IBM lays out in its i5/OS and related software--Installing, upgrading, or deleting i5/OS and related software Version 6, Release 1 Redbook (SC41-5120-10).

In short, we've done everything I said we should do in my Getting Started With An i 6.1 Upgrade article.

So we're ready to go. The next step is to come up with our installation plan.

And Now The Plan

Outside of using IBM's materials, here are the additional steps we'll be taking to install the upgrade. These steps do four things:

1. Clear the way to upgrade the system--Finding the proper time to upgrade the system when no one else is using it and performing final checks.
2. Perform risk avoidance and mitigation--Taking steps to ensure we can recover if the system upgrade fails.
3. Gather necessary materials--Making sure we have everything we need for the upgrade, including backup media, paper copies of instructions, etc.
4. Create the upgrade schedule containing before, during, and after-upgrade tasks--Compose the upgrade schedule for the day of the upgrade.

Step #1: Clearing the way to upgrade the system

This step includes clearing our upgrade plans with management and associated groups working on the backup. This weekend, we're only upgrading our development partition so scheduling won't be as difficult as it will be when we upgrade the production partition. Checklist items in this step include:

• Final check-off that all system objects that cannot be converted to i 6.1 format are dealt with.--Everyone has been clearing away old libraries, contacting vendors about what to do with third-party unconvertible objects, and prepping our system for object conversion after the upgrade finishes. For this upgrade, we ran the Analyze Object Conversion (ANZOBJCNV) command one last time and listed the results to make sure we didn't miss anything.
• Schedule the upgrade window.--While it isn't as big a hassle to upgrade a development system as it is to upgrade a production system, we still have to schedule about 12 to 15 hours of downtime to perform the upgrade and all its attendant processes. We'll be performing this upgrade on Saturday morning. The downside is that our applications group won't be able to use the system all day.

Step #2: Risk avoidance and mitigation

This step covers contingency planning in case something goes wrong. The idea is to brainstorm all the scenarios where problems can occur and diagram what we will do if any of these scenarios happen. For this upgrade, we are planning the following steps to avoid a foreseeable event from happening (risk avoidance) and to mitigate the effects of a foreseeable upgrade issue occurring (risk mitigation).

For our development partition, we have identified the following plans that can be implemented in response to our identified risks, if necessary.

• Unforeseen event delays upgrade form completing--We are scheduling recovery time in case we can't get the upgrade completed in our upgrade window. We will purposely upgrade the system on Saturday, so that we have time to recover on Sunday if delays or problems occur.
• Need to restore the system to its prior version if the upgrade fails--Make sure we have two sets of backup media handy to restore the prior system. The second set of media is insurance in case we have a problem restoring from the first set of media. Our two sets of backup media will be: A full system backup taken immediately before the upgrade; and the last full system backup taken the Sunday before the upgrade, along with the latest incremental data backup tape generated the night before the upgrade. If the pre-upgrade backup media fails for some reason, we can use the secondary media to restore the system.
• Image catalog cannot be used for installing operating system upgrade and PTFs--We are installing from an image catalog for this upgrade. However, if we're unable to use the catalog, we will fall back to installing from DVDs.

Step #3: Gather necessary materials

Here, we make sure that we have all the materials we need to perform a successful upgrade. We refer to this as putting together our crash cart. Low tech in nature, the crash cart is a good study box that contains the following materials we'll need for the upgrade.

• Last full system backup that occurred before the upgrade--This is the last full system backup of the development machine taken before the upgrade (our secondary backup).
• Last incremental system backup--To be applied on top of the secondary full system backup, if needed.
• Scratch tapes for after-upgrade backups--We will be performing a system backup (SAVSYS) and a special full-system backup after the upgrade. So we need special media to save these images on.
• Upgrade DVDs that we loaded to the image catalog--We are planning to install from an image catalog but if something goes wrong, we may need to use the DVDs to complete the installation.
• Cumulative and group PTF DVDs--Same as with the upgrade DVDs, we want to have these readily available in case the image catalog doesn't work.
• Upgrade instruction manual--Our marked-up version of the i5/OS and related software--Installing, upgrading, or deleting i5/OS and related software Version 6, Release 1 Redbook (SC41-5120-10), which contains all the upgrade instructions and our notes. This is our bible for actually upgrading the system.
• IBM licensed program keys (hard copy)--New keys for licensed programs to run under i 6.1, received from IBM.
• After upgrade instructions--All the procedures that have to be done after the system is upgraded. These are notes from vendors on how their software needs to be changed to run on i 6.1. Some software needs to be reloaded after the upgrade in order to run correctly. Some software needs to be modified, such as our change management software, which needs to be reconfigured to promote objects to the prior version.
• Phone numbers and email addresses of all team members working on the upgrade or who need to be notified of upgrade process--To contact the system shareholders when the upgrade is completed or if we run into issues with the upgrade.
• Schedule--Copy of the schedule in step four.

Step #4: Scheduling before, during, and after-upgrade tasks

For the entire i 6.1 upgrade project, we created a Gantt chart to track our critical path and necessary tasks. Gantt charts are great for projects like this because you can see the necessary flow and more easily assign resources to the project.

However, we needed something simpler for the upgrade weekend. So we created the following schedule to guide us through all the upgrade tasks we'll be performing on Saturday (all times are approximate).

• 4 a.m.--Change system start-up program to *NONE (QSTRUPPGM system value), so that the system doesn't restart after the full system back-up or an IPL
• 4 a.m.--Full system backup for emergency restore in case the system needs to be reloaded
• 4 a.m. - 10 a.m.--Full system backup running
• 10 a.m. - 4 a.m.--IBM i 6.1 upgrade and applying PTFs and licensed products: Upgrade system; apply necessary group and cumulative PTFs after the upgrade; apply IBM licensed program keys for i 6.1
• 4 p.m.--Start object conversion
• 7 p.m.--After upgrade activities: Perform operating system save with the Save System (SAVSYS) command; apply post-upgrade third-party procedures; and system testing
• Earliest opportunity--Full system backup

To Find Out How it Went

Through the magic of publishing, I'm writing this on Thursday, April 12, and we're scheduled to perform the upgrade on Saturday, April 14. That means I'll be finished with the upgrade by the time you read this.

However, I'm planning on semi-live blogging the upgrade as we go along, so you'll be able to see the results of our planning. To see how we did, go to joehertvik.com and you'll find links to our upgrade adventure on the main page.

See you next week.

Follow Me on My Blog, on Twitter, and on LinkedIn

Check out my blog at joehertvik.com, where I focus on computer administration and news (especially IBM I and soon PureSystems); vendor, marketing, and tech writing news and materials; and whatever else I come across.

You can also follow me on Twitter @JoeHertvik and on LinkedIn.

Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.

RELATED STORY

Getting Started With An i 6.1 Upgrade

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot