Four Simple Rules For IBM i PTF Management
March 21, 2012 Joe Hertvik
Talking with an IBM Business Partner this week, the conversation turned to PTF management and the best ways for managing cumulative PTFs. Inspired by this talk, I came up with these four simple rules for a good PTF management strategy.
Rule 1: Don’t Let Your PTFs Age
A lot of shops only apply PTFs when they upgrade their hardware, but many (or most) shops are also frequently upgrading their application software. Frequent application changes can create new processing situations that test the limits of a partition’s Licensed Internal Code (LIC) and operating system fixes. In a rapidly changing applications environment, it’s more important than ever to keep current with PTFs.
I’ve seen two situations in the past year where an IBM i system went down during the production day and the fix was to apply more current PTFs. So while IBM i systems may be the most reliable computers on this or any other planet, operating system errors can also happen to these partitions if you’re not current on fixes.
So don’t let your cumulative PTFs get too old.
Rule 2: Don’t Rush Cumulative PTFs. . . Maybe
Conventional wisdom says don’t rush to put cumulative PTFs (cumes) on your system as soon as they’re released. The fear is that if IBM releases a bad PTF on a cume, it may take a month or so for them to realize it. So the thinking goes, if you wait a month or two after the cume is released, IBM will have time to correct any bad PTFs it may have released with the package.
The jury is still out on this one. There are plenty of people who religiously put cume PTFs on their system without any problems. So I’m not sure if waiting to apply cume PTFs is a valid action or not. If anyone from IBM who is knowledgeable about cume PTFs is reading this, please email me to let me know whether Big Blue corrects PTF package after they hit the system. I’d be curious to see how much truth there is to the conventional wisdom out there.
Until I hear otherwise however, I’d stick with the common wisdom and wait a reasonable time (say a month after release) before ordering and applying cume PTFs on your system.
Rule 3: Apply PTFs To Your Partitions In The Proper Sequence
If you have several different partitions that serve different functions for your shop, there’s a definite sequence you should follow to apply the same cumulative PTF package to each partition. IMHO, here’s how I believe cumes should be applied across all your various partitions.
1. All new PTF packages go on the development partition first–Development partitions are made for testing software fixes and modifications. Put any new PTF packages on your development partitions first and let them run on the box for at least a week before you post the PTFs to another partition. That way you’ll have some confidence that the act of applying these PTFs will not harm your production systems. And if there is a bad PTF on the partition, running it on development for a while gives you time to discover the issue before it goes to production.
2. High availability (HA) or backup partitions get new PTF packages second–HA and backup partitions should always get PTFs before your production box. Again, this provides some time for bad PTFs to show themselves without taking down your production system. And once you apply PTFs to both your development and your HA partitions without incident, you’ll have a much higher confidence level that your PTFs won’t damage your production system.
3. Special purpose partitions receive PTFs next–If you have a partition that’s devoted to a certain function, that partition should be the next one to get your PTF package. For example, if you have an isolated IBM i partition that runs credit card processing in its own secured network for PCI compliance, apply your PTFs to that partition before applying them to your general production partition. Again, this is part of the vetting process to ensure that all PTFs go on smoothly before going to production.
4. Main production partitions receive PTFs last–If you apply PTFs in this methodical style, you’ll have pretty good confidence that you won’t have any problems applying PTFs to production.
Rule 4: Pick Your Poison For A Production System PTF IPL
When you IPL your system to apply PTFs is almost as important as how you apply your PTFs. With most partitions running 24x7x365, finding a time when you can take your system down for an IPL can be a delicate maneuver. For PTF applications, you always have to find a time when the system is relatively quiet for IPLing. But that time can depend on a number of situations, including:
It’s wise to know your company’s processing pain points and to schedule PTF IPLs around those events. For most partitions, an IPL isn’t a long enough event to trigger a switch-over to a Capacity BackUp (CBU) system. So until you migrate to a high availability solution that can perform an immediate switch-over, you will still have to deal with your company’s processing schedule.
Not The Only Rules, But A Start
Take these PTF rules as just a starter guide for your own PTF strategy. Feel free to email me your own ideas for PTF management, and maybe I’ll cover those ideas and more in a future column.
Great PTF reference available
It’s also worth noting that IT Jungle publishes the System i PTF Guide, a complete listing of all PTF group levels and the last dates each PTF group was changed (including HiPERs and Cumulative PTFs). This site is worth checking on a regular basis when you’re looking for fixes.
Follow Me at My Blog, on Twitter, and on LinkedIn
Come check out my blog at joehertvik.com, where I focus on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else I come across.
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.