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. 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.
|
I know this excellent post is over 10 years old but I would add a couple things:
(1) IBM i CUMEs are tested and are a set of PTFS that are known to work together. Not just any PTF can go on a CUME and there is extensive testing involved of the ones that do. Also, the PTFS on a CUME are not ones that just came out, but ones that are known to be good fixes for very common issues you want to avoid.
(2) While there is some wisdom to staying a CUME back, there is no excuse for being 2+ years back.