Admin Alert: Readers Check in on Four Simple Rules for PTFs
April 4, 2012 Joe Hertvik
|
After posting my March 21st article on Four Simple Rules for PTF Management, I received so much good information from our readers on PTFs that I decided to pass it along in this follow-up column. Here’s some additional tips and techniques on PTF management that might make it easier to apply PTF fixes on your IBM i machines. Q: When does IBM refresh a Cume PTF package? A: Never Reader Richard Shearwood wrote in with this piece of information about whether IBM corrects cumulative PTF packages containing bad PTFs after the package is released. IBM never refreshed a cume PTF package with new content as far as I can tell. But they can and do replace cumulative PTFs pretty quickly if they need to. I haven’t seen it for a while but back in 2006, a cume PTF had a major defective PTF that could require a reload of the Licensed Internal Code (LIC) to remove. So the next cume PTF after that was released just 41 days later. Full details are inSF98088 (V5R3 defective PTFs) for the morbidly curious. Speaking of defective PTF packs, you might have come across a bug in the latest i 7.1 cumulative pack–or, indeed, several bugs. One or two key PTFs have incorrect CoReq/PreReq specifications and the pack will not apply if the previous pack is too old. In this case, you need to apply PTF 5770999 MF54291 as a *TEMP PTF with all its PreReq PTFs and then do the same for PTF 5770SS1 SI45000. Change your IPL attributes to IPL into restricted state with the following Change IPL Attributes (CHGIPLA) command: CHGIPLA STRSTD(*YES) IPL your machine and once the machine comes up in restricted state, carry on to re-apply the pack. Thanks, Richard. That’s good information on the bug in the i 7.1 cume package. It’s things like Richard’s 2006 story where a defective PTF has an adverse effect on your system, that led me to adopt rule #2 in my PTF Management article, Don’t Rush Cumulative PTFs. Wait a reasonable time before applying a cumulative PTF package after it’s released, at least a month. And be sure to check IBM’s Preventive Service Planning (PSP) Defective PTFs page for the latest on bad PTFs for each release and what to do about them. Here are the links to the PSP Defective PTFs pages for each of the currently supported releases. Simple Rules Five, Six, and Seven for PTF Management? The following general PTF management suggestions came from an IBMer who wrote in. Some of these ideas might be considered extensions to my four rules of PTF management. 1. Take a snapshot of the following key system information prior to loading or applying PTFs. This gives you a baseline in case of post-PTF issues.
2. Capture or save pre-PTF performance baseline information so if issues arise after the PTF apply, you have data to compare your performance to. 3. Develop a test plan to thoroughly exercise system functions and application code so that the post-PTF testing done on the development system will really test the PTFs. There are good suggestions for everyone to minimize any adverse effects a cume PTF package might have on your system. In particular, these steps may serve you well if you’re in a Sarbanes-Oxley (SOX) environment, where there may be a greater requirement to document PTF testing before and after PTF application. I run a Data Center for two different companies, one of which falls under Sarbanes-Oxley. I can tell you that the requirements for the SOX environment are much more stringent for doing things like applying PTFs. Following these steps might help when the auditors come around. Don’t Waste Time Before Installing Hiper PTFs And then there was this suggestion from Luis Rodriguez about the need to rush Hiper PTFs on to your system. To Rule #2: Don’t Rush Cumulative PTFs…Maybe, I would add: Rule 2b: RUSH with Hiper PTFs. . . (After carefully considerations, of course)rnHiper PTFs are High Impact/Pervasive for a good reason. If you check the Hiper PTF list and it looks as if one of them could apply to your system, don’t waste too much time installing them. Regarding cume PTFs, I belong to one of those lucky souls that never (AFAIK) had a problem with them. The one month rule [before applying cumulative PTFs after the cume package is released] is always good, though. I’ve had the same experience as Luis, where I’ve been lucky and have never had a problem with bad cume PTFs on my machine (hope this doesn’t curse it). That said, I still think I’d go with waiting a month to see what happens before applying the package. Which Came First, The Group PTF or the Cume? Similar to the common question about the chicken or the egg, Ed Evers wrote in with this puzzling query. I have heard (quite a while ago) that a faster way to apply PTFs was: For existing systems: Apply group PTFs prior to applying the new cume. For new installs: Apply cume first, then apply groups. Any truth to that? I have never tried to apply group PTFs before the cume package. I always apply the cumulative PTFs first. I have to confess that I don’t know the answer to this. However, if anyone reading this has any information on this topic, please email me through the IT Jungle Team Web site However, I’m not sure why there would be a difference in your PTF load/apply sequence between existing systems and new systems. My gut feeling is that in all instances, the cume should be loaded first before the group PTFs. I usually load both the cume and the group PTFs at the same time through option 8 (Install program temporary fix package) on the Program Temporary Fix (GO PTF) menu. If I change the Prompt for Media parameter to 2=Mulltiple PTF volume sets, Option 8 will prompt me for additional PTF sets after I finish loading the cumulative package. After I load both PTF packages, I then apply them at the same time with an IPL. This load sequence makes sense to me because I’m much more likely to have any PreReqs and CoReqs for the group PTFs loaded before the group package is loaded. Again, I’m not sure why loading one set of PTFs before the other would make a difference but like you, I started doing it this way a long time ago and I never broke the habit. Follow Joe Hertvik on His Blog, on Twitter, and on LinkedIn Check out Joe’s blog at joehertvik.com, where he focuses on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else he come across. You can also follow Joe 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 Four Simple Rules for PTF Management
|
