No Shortcuts to Program Conversions, OS Upgrades
October 18, 2010 Dan Burger
|
Somewhere someone is about to take a stab at upgrading an IBM i operating system to version 6.1 or 7.1. The probability of mistakes being made is pretty high. The trouble resulting from those mistakes will range from easily correctable to call in the cavalry. The difference can be nailed down to two factors: poor preparation and too little time allotted for completion. Yes, we’re talking about program conversion, which often has more bark than bite. When you do more than 75 of these OS upgrades in the past year, and more than 200 total, you see the commonly made mistakes. Advice comes from experience. That’s why I called Pete Massiello, a guy who knows the ropes by virtue of the aforementioned hundreds of upgrade experiences. Massiello’s company, iTech Solutions Group, considers Connecticut and the Northeast as its base of operations, but has clients nationwide. You may be more likely to have heard his name in association with COMMON. He currently serves as that organization’s president. During a telephone conversation last week, Massiello suggested that an article a week for the next two months would probably not completely cover the topic of IBM i upgrades, but he agreed to focus on a few briar patches that are causing a lot of misery. The thorniest topics surround what can and cannot be accomplished with Analyze Object Convert (ANZOBCVN) utility provided by IBM to identify objects that will not be converted during the upgrade process. It’s not uncommon for an upgrade to be attempted without using the tool or by misusing the tool. “Either way, you’re screwed,” Massiello says. “Anytime you cross the 6.1 boundary, you need to run Analyze Object Convert,” he advises. “Analyze Object Convert is a process you run for as many times as it takes until it comes out clean. If it doesn’t come out clean, the objects listed on the report it generates cannot run on 6.1 or 7.1. You have to get a clean report.” Massiello recommends the first pass with the Analyze Object Convert utility be scheduled three months prior to the planned upgrade date. That’s because the likelihood of sorting out the issues that it brings to light will take some time. In almost every case, the person who runs it on Thursday afternoon and expects to upgrade on Saturday is going to be disappointed. “You’re not going to have one program to convert. You’re not going to have 12. I’ve been on accounts where thousands of pages of objects that wouldn’t convert were generated,” he says. “Only once in all the upgrades I’ve done did a system pass the Analyze Object Convert procedure on the first time. That happened because the company had no third-party applications on their box. Therefore observability was never removed from any applications.” Observability and its subset, creation data, are like a DNA link a specific identifier that is unique to all machine interface programs. Either creation data or observability is required to re-encapsulate the object when the conversion takes place. Most third-party vendors remove observability to protect their intellectual investments in RPG code. With V5R1, IBM made it possible to remove observability, but the creation data that gives you the ability to re-encapsulate an object remains. Programs compiled at V4R5 or earlier with observability removed cannot be migrated across the IBM i 6.1 boundary, Massiello points out. Because the only upgrade paths to i 6.1 are from either V5R3 or V5R4, Analyze Object Convert only runs on those two releases. The conversion utility has two phases. The first is a collection phase, which is a long-running batch job. It’s followed by ANZOBJCVN, which then generates reports detailing the library summary (how long each library will take to convert) and the conversion problems. Almost all of those will be vendor programs, Massiello says. “In 99 percent of those situations, you call the vendor and say, ‘I’m running your software and I’m thinking about going to 6.1. I ran Analyze Object Convert. I got some issues. I need the 6.1-compatible version of your software.’ And the vendor says, ‘You’re under maintenance. No problem. We’ll send it out.’ Where you get screwed is when the vendor says, ‘You are not under maintenance. You cancelled maintenance.’ When people cancel their maintenance, they can’t move forward. Most third-party packages that you haven’t upgraded in a while will give you issues.” When the software vendor no longer supports the version your company is running, there’s a good chance you’ll have extra work when moving to a 6.1-compatible application. You’ll need time for retrofitting the modifications and determining the impacts. That may not amount to much if you have a “vanilla” package. But the vendor may have changed product functionality in subsequent releases while you’ve lagged behind. Massiello’s advice is to test to make sure changes won’t negatively affect your business. “A lot of the customers go through this process with the vendors and everything is fine,” he says. “But after you go through these steps with the vendors, you have to run Analyze Object Convert again to make sure there are no issues. In addition to pointing out which objects will not convert and allowing you to take the steps to overcome those obstacles, an Analyze Object Convert report will indicate how long each library is going to take to convert. The majority of upgrades can be accomplished in six to 12 hours. After everything is analyzed on the old release and it receives a clean report, test the software to make certain everything to make certain it performs as expected. When you move forward with the upgrade, the programs get converted within IBM i on what is referred to as “first touch.” But Massiello warns not to leave it to your users to have that first touch. Users will get bogged down with programs being converted as they call them, he says. By converting them before they are available to users, it avoids the performance drag that first touch users experience. “A successful upgrade is one that no one knows took place” is his reasoning. In one instance Massiello was involved with, the customer faced a 68-hour conversion time when going from V5R4 to 6.1. To smooth that conversion, his company converted all the client’s programs on the iTech Solutions’ machine. The programs were then packaged and restored on the customer’s machine, which only took an hour to install. Among the other “gotchas” that Massiello frequently finds as the cause of upgrade frustrations are attempts to upgrade without updating firmware, not realizing that some of the older models of iSeries hardware (models 800, 810, 825, 870 and 890, for instance) do not support the new releases of the IBM i operating system, and not loading the necessary PTFs. He also recommends a backup before upgrading and another after the upgrade is complete. Most people would know to do that, he says, but sometimes best practices are ignored in favor of saving time. There are several sources of information that will benefit the planning and implementation of a software upgrade to 6.1 and 7.1 from earlier versions of the operating system. Two that are recommended by Massiello are the i5/OS Memo to Users for V6R1 and the i5 OS Installation and Planning Upgrade Guide. You can also find upgrade planning information at this link and the IBM Redpaper titled IBM i Program Conversion: Getting Ready for 6.1 and Beyond. RELATED STORIES i For Business Gets to Lucky Number 7–Dot 1 The i 7.1s Have It; i5/OS V5R4 Extended Bracing for i5/OS V6R1 and the Winding Down of V5 Global Services Offers i5/OS V6R1 Migration Help i5/OS V6R1 Compatibility an Issue for Software Vendors i5/OS V6R1: The TIMI, It Is A-Changing
|
