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

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.



About Jay Kruemcke

Jay has had more than twenty years of experience in the information technology industry. Starting from a rather humble beginning at IBM, Jay became a mainframe systems support programmer. Eventually Jay joined the AIX operating systems development team early in that product's development. Jay leveraged technical skills that he built in systems management to establish himself as a member of the IBM Austin Executive Briefing Center. His expertise in systems management with the SAP ERP system enabled his first product management role, as the owner of the Tivoli management product for SAP. Over the next three years he established that product as a success with the help of a strong development team. Jay returned to AIX in a product management position initially focusing on managing new requirements for the AIX operating system. Jay established himself as a subject manager expert in AIX and Power Systems virtualization and became a frequent guest at conferences around the world. Jay succumbed to the dark side and spent four years in IBM marketing in which he introduced AIX version 6 and AIX version 7 and many product innovations including the first every open beta program for an AIX release and a significant restructuring of the AIX offering structure and prices. Jay was part of the cloud software development organization and and focused on managing development engagements for clients deploying clouds using Power Systems servers with PowerVC and related products. In March of 2016, Jay retired from IBM and started in a new role as a product manager for SUSE, the Open Software company. Jay new focus is on enterprise Linux for POWER and ARM processor based systems. 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, @cloudrancher and @chromeaix.
This entry was posted in AIX & Power Systems Blogroll. Bookmark the permalink.

One 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: Logo

You are commenting using your 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