Admin Alert: Four Things to Beware of During a System Upgrade

January 28, 2009 Joe Hertvik

As I reported a few weeks ago, i5/OS V5R3 loses IBM support as of April 30th, which may cause many iSeries and System i shops to upgrade their operating systems in the next few months. If you’re currently working on a V5R3 upgrade, here are four things that you should watch out for as you plan your upgrade.

Be Aware of the Difference Between Compatible and Supported Software

For third-party software, it’s important to understand the difference between a compatible and a supported piece of software. I recently ran into this issue on an i5/OS V5R4 upgrade where the vendor told us that their software wasn’t supported on i5/OS V5R4 and that we needed to upgrade the software before we upgraded our operating system.

While we were wondering whether a third-party software upgrade would delay our system upgrade schedule, we decided to give the vendor another call. The tech who answered this time told us that we would be okay with the upgrade. The software was compatible with the new operating system but it was no longer supported by the vendor, because it was an older version of the software. The old software could run on the i5/OS V5R4 operating system but the vendor was no longer supporting users who choose to run it on the new operating system. In our case, this worked out fine because the software was stable and we hadn’t needed to log a support call for several years.

It’s best to get your terms straight when dealing with vendors. Better yet, ask the vendor to define their terms for you. Generally, if the software is listed as compatible, it will run on your new operating system. If it’s not compatible, you will need to upgrade or replace the software for the new system. If the vendor says the software is supported, they will support you in trying to make the software run on your system. If the software isn’t supported on the new system, it may still run after the upgrade but if you run into problems, you probably won’t be able to get vendor support to make it work.

Be careful however when upgrading to i5/OS V6R1. Many older third-party software packages lose compatibility when you perform a V6R1 upgrade, and the packages have to be upgraded to the latest version to run on V6R1.

Don’t Forget Your HMC

If you’re using a Hardware Management Console (HMC) to control your partitions, make sure that your HMC software level is compatible with the new operating system. You can check this out by working with your iSeries/System i/Power i business partner or by calling IBM technical support to determine if your operating system and HMC levels are compatible. If you need to upgrade your HMC, make sure that you perform the upgrade before you perform your i5/OS upgrade.

Read the Freakin’ MTU (Memorandum To Users)

If you do nothing else to plan for your upgrade, make sure to read the following manuals that IBM provides.

IBM Systems–iSeries Memorandum to Users–This manual lists out all the release modifications that can affect your system or programming operations. It describes all the operating system changes as well as program options and licensed program changes. The Memorandum will give you an idea of where you may run into problems with new operating system features and discontinued features. It’s also important to remember that the Memorandum should be passed around and read by multiple groups in your shop. In addition to your system administrators, parts of the Memorandum should also be read by system and application programmers, Web programmers, and any others who access your system from outside the box. You may even want to run certain section past some of your more savvy power users. Memorandum information is critical to a number of different people so don’t be stingy. Pass it around.

You can find the Memorandum to Users for Version 5 Release 4 Upgrades by clicking here. For i5/OS Version 6, Release 1, IBM changed the manual name to the System i i5/OS Memo to Users and you can find that manual by clicking here.

In addition to the Memorandum/Memo to Users publications, IBM also has an IBM System i Support: Planning–Migration and Upgrades Web site. This site provides all kinds of useful information for working with current i5/OS releases (V6R1, V5R4, and V5R3) including hardware upgrade information, data migrations between servers, software upgrades, and aids for migration and upgrade. This is also recommended reading if you’re going to perform an upgrade.

Saving/Restoring Objects Between Systems

If you’re working in a multi-partition environment that may include a development partition, production partition, and a Capacity BackUp (CBU) machine, be careful with your backup and restore scheme as you are going through the upgrade cycle. As I wrote in my previous article, you should upgrade partitions in a multi-partition environment in the following sequence.

Upgrade the development box first
Upgrade the CBU second
Upgrade the production machine last

When you have three different partitions like this, it’s a clear bet that you won’t be upgrading all three partitions on the same weekend. Most administrators would vote to upgrade the development partition first, let it run for a set amount of time (say a week), and then upgrade the CBU and the production partitions in later weeks. This means that your partition operating systems will probably be out of sync for a certain period of time. All of which can cause problems if you need to restore backed up files from one partition/machine to another. This can happen when you are using your CBU to back up production data, in order to leave your production system active 24×7. If you upgrade your CBU before your production box, then you may have difficulty restoring backed up files to the production partition running at a lower operating system level. In certain cases, you may also have automated routines that transfer files from one box to another at certain times of the day.

If you think that you’ll need to restore saved data from a higher i5/OS operating system to a lower operating system level, you may need to temporarily rethink or retool your save operations to ensure that you can restore the files to the proper i5/OS operating system, if necessary.

To keep backed up objects in sync with a lower level operating system, each i5/OS SAVxxx command has a parameter called “Target Release” (TGTRLS), which allows you to specify the release of the operating system that you intend to restore to. TGTRLS’ default value is *CURRENT, which tells the operating system to save objects so that they can be restored to and used on whichever operating system your machine is currently running on. However, TGTRLS has another settable value called “Previous” (*PRV), which saves objects so that they can either be restored to the current operating system or to the prior release of the operating system.

So if I specify a TGTRLS value of *PRV in a SAVOBJ command on a V6R1 operating system, those objects can be restored either to another V6R1 system or to another partition running i5/OS V5R4 (the previous release). If I run a SAVOBJ command with a TGTRLS parameter of *PRV on a V5R4 system, those objects could be restored and used on either another V5R4 or a V5R3 operating system.

Here’s how a Save Library (SAVLIB) command looks when TGTRLS is set to *PRV:

SAVLIB LIB(library_name) DEV(device_name) TGTRLS(*PRV)

The TGTRLS parameter is available on most i5/OS SAVxxx commands, including Save Object (SAVOBJ), Save Library (SAVLIB), Save Document Library Object (SAVDLO), Save Changed Objects (SAVCHGOBJ), and Save (SAV).

So if you need to restore objects between companion partitions whose operating systems are temporarily out of sync, you may want to look at your backup routine to ensure that you’ll maintain restoration capabilities during the upgrade cycle.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search