IT Jungle: Four Simple Rules for PTF Management

Posted on by Joe Hertvik

IT Jungle just posted my latest tip on four tips for PTF management

If you don’t want to read the article but need more information on the PTFs needed by your machine, check out IT Jungle’s System i PTF Guide. Maintained by DLB Associates and updated weekly, this is a great place to go when you’re unsure which PTFs to order.

***************************************************

Follow Joe Hertvik on Twitter @JoeHertvik. You can also add Joe to your professional network on LinkedIn by clicking here.

Joe Hertvik is the owner of Hertvik Business Services, a company that produces White papers, case studies, brochures, email campaigns, and other on-line marketing material for Tech companies. If you need professionally written marketing content for your next campaign, email Joe for a free quote.

Related Posts

About Joe Hertvik

Joe is the owner of Hertvik Business Services, a service company providing written white papers, case studies, and other marketing content to computer industry companies. He is also a contributing editor for IT Jungle and has written the Admin Alert column for the past ten years. Follow Joe Hertvik on Twitter @JoeHertvik. Email Joe for a free quote on white papers, case studies, brochures, or other marketing materials.
This entry was posted in IBM i Tech Info. Bookmark the permalink.

One Response to IT Jungle: Four Simple Rules for PTF Management

  1. Jozsef Torok says:
    March 26, 2012 at 6:20 pm

    Hi Joe,
    For your Rule 3, do you see a case for using a slightly different sequence? Applying a new CUME on development/testing LPARs first, then Production and lastly the Production backup/HA LPAR?
    The justification for that is if a new CUME PTF causes the Production LPAR to go belly up, we can be confident that the backup LPAR (without the offending PTF) will operate fine.
    There will be arguments for and against our process, and the following example sort of falls in between. It more relates to your Rule 2.
    We are running i 6.1.0 and recently applied CUME C1256610, as it happens lastly on our Production LPAR. This CUME contains MF53085 (superseded by MF54555) which, once applied, runs a “clean-up” task that is going through and verifying certain internal object headers. This ran fine with no discernable impact to all our non-Production and Backup LPARs. But when it was applied on Production, we certainly noticed its impact with our ASP1 disk showed non-stop very high %Busy figures. The WRKSYSACT display showed 12 SMEHDRWORKER tasks causing the very high I/O. After logging a PMR with IBM we found out that the SMEHDRWORKER tasks are Storage Management (SM) Embedded Header (EH) fixers that are low priority tasks mainly doing read/writes to verify everything is ok. Although the ASP1 were very busy thankfully our other performance KPIs weren’t impacted as ASP1 is essentially our system ASP only, utilising other ASPs for the application software and database.
    The good thing was that IBM also provided instructions for pausing the header checker process via the Advanced Analysis SMPAUSEHEADERCHECKER macro. This macro has a parameter which is a number between 8-24 that corresponds to the number of hours the task will be paused.
    After watching this process run (with pauses) for five days, IBM suggested we clean up any Main Store Dumps, of which we had three. As soon as those MSDs were removed, the process completed within 40 minutes. Interestingly the same process had run a week earlier on our Production backup system, which also had some MSDs on it, but the process ran to completion within a couple of hours.
    We will never know now why the process ran for so long on out Production LPAR as we didn’t end up running any traces. But it has prompted us to raise with IBM why they don’t publish some sort of PTF alert for PTFs like this that can potentially impact a system.

    Regards,
    Jozsef Torok

Comments are closed.