AIX Service Pack best practices

As discussed previously, IBM periodically delivers new function, new hardware support, and cumulative fixes for AIX in software updates called “Technology Levels”.  The name “Technology Level” was created in 2005 to replace the former name “Maintenance Level”. The new name indicated that a “Technology Level” wasn’t just a bundle of fixes, but may also include new functionality.  Technology Levels are now released once per year, and are a way for IBM to deliver cumulative fixes, functional enhancements and new hardware support between new releases/versions of the AIX operating system. Not all Technology Levels include functional enhancements, but all Technology Levels provide cumulative fixes and new hardware support.

Service Packs have a very similar purpose but there are some key differences. First, Service Packs are released about four times per year to deliver cumulative fixes and new hardware enablement on top of an existing Technology Level.  Second, Service Packs do not include functional enhancements. Since Service Packs do not include new function, they are viewed by many administrators as potentially less likely to introduce problems.

The ability to install individual fixes to AIX on a piecemeal basis, called “Selective Fixes”, was introduced in AIX Version 3.2 in 1992.  Selective fixes were a highly requested capability because with selective fixes, clients could pick and choose which fixes to install.

This seemed like a great idea; after all, shouldn’t installing only the fixes that you really needed reduce the risk of an update destabilizing your system? Well, unfortunately, the answer turned out to be “not so much”.

The challenge with selective fixes is how to manage the dependencies, also known as “requisites”, between different functional areas within AIX. For example, fixes to one area (such as NFS) might be dependent on a requisite fix being made in another area (such as the kernel).  The effect if this was that if you wanted to update NFS, you also had to also make sure you also made the requisite update to the kernel.

The knowledge about which fix requires which requisite fix comes from the developer. The developer has to code knowledge about co requisites into the individual fixes so that when you installed the NFS fix in the example above, the corresponding kernel fix was also installed.

Unfortunately, we observed that a number of the problems that clients were experiencing in the field were the result of hidden requisites between code areas. While it was relatively easy for a developer to understand and manage the requisites for code changes that she had introduced, it became difficult to manage the unintentional requisites that naturally occur in a complex environment like an operating system.

The irony is that when an administrator thought he was reducing risk by introducing fewer changes to the operating systems, he was in fact becoming a test pilot – a test pilot that was running a combination of components that had likely never been run before.

To avoid this issue, we came up with only one approach that is guaranteed to work: clients should install all the fixes at the same time. After all, IBM tests all fixes in a service pack (or Technology Level) as a unit so if clients install all the fixes (update_all) , then the client is using the same combination that IBM tested. This recommendation is part of the “IBM AIX Operating System Service Strategy Details and Best Practices” documented at http://www14.software.ibm.com/webapp/set2/sas/f/best/home.html

While IBM has not disabled the selective fix capability in AIX, we have made it more difficult to use by disabling the ability to download individual fixes from Fix Central – you must download the entire service pack. You can still extract and install individual fixes, but we don’t make that risky behavior easy.

In summary, IBM provides Service Packs for AIX because it is the best way for you to maintain the operating system. While it may be counter-intuitive, periodically installing all fixes in the Service Pack is the best way for you to maintain the AIX operating system between Technology Level updates and it is least risky way to update your AIX system.

Jay

About Jay Kruemcke

Jay Kruemcke is passionate about helping customers and partners achieve their goals. Jay is a currently a Senior Product Manager at SUSE. Jay is responsible for the SUSE Linux for High-Performance Computing, Linux for Arm, and Linux for Power servers. Jay released the first commercially supported Linux distribution for Arm in 2016. Jay completely restructured SUSE’s HPC offerings in 2017 to add support for Arm systems, provide longer term support, and continue to enhance the HPC Module. The HPC Module provides support for open software such as slurm as part of the SUSE HPC subscription. Jay has built an extensive career in product management based on being a bridge between customers and engineering teams. He has extensive experience in many areas including product positioning, driving future product directions, using social media for client collaboration, and evangelizing the capabilities and future directions of enterprise products. Prior to joining SUSE, Jay had a long career at IBM including many roles in the Power and Cloud Engineering and Offering teams. In addition to his product management experience, Jay has held a variety of technology roles at including product marketing, manager of a technical architecture team, briefing center staff, SAP systems management consultant, and as a system programmer and administrator Jay also volunteers with the Boy Scouts in multiple roles and with ProductCamp Austin. The postings on this site solely reflect the personal views of the author and do not necessarily represent the views, positions, strategies or opinions of my employer. Follow me on twitter @mr_sles and @phastflyer
This entry was posted in AIX & Power Systems Blogroll. Bookmark the permalink.

1 Response to AIX Service Pack best practices

  1. A very important and strong message for my company clients!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s