Some “Whys” about AIX Technology Levels and Service Packs

Here are the answers to a couple of “Why” questions that I have gotten recently about how we roll out AIX fixes such as Technology Levels and Service Packs.

The first question:

“Why does a new Service Pack comes out at the same time as a new Technology Level?”

As you might imagine, testing a new AIX Technology Level is a very involved process that takes many months. As with any complex software, it is impossible to get to a point where all problems have been discovered and resolved. The process of releasing a new AIX Technology Level involves testing the code and evaluating the severity and impact of problems found to decide when the code is good enough to be released.

For example, a bug that caused a data integrity issue would be a severe enough problem that it would have to be fixed before the Technology Level could be released. In contrast, a typo in the man page would not be severe enough problem to hold up the release of the Technology Level.

As the testing of a Technology Level progresses, the product team tracks the severity of the new problems and the resolution of previously discovered problems against established quality criteria. Over time, the severity and number of new problems discovered during testing tapers off and most of the problems that have been discovered would have been resolved. At this point the quality of the Technology Level meets the quality criteria and the Technology Level is ready to be released to the distribution channels.

When I say “distribution channel”, I am talking about the two main ways that clients can obtain the new Technology Level: via Fix Central as downloadable update or as new bootable installation media that is physically replicated in multiple IBM distribution centers around the world.

It takes some period of time for new Technology Level to make it’s way through these distribution channels (such as time for the physical media replication), thus the new Technology Level has to be released to the distribution channels before it is actually available to the clients.

The key thing to understand is that we don’t stop testing the new Technology Level even though it has been released to distribution. In fact, there is ongoing testing of AIX going on all the time.

As we continue testing the Technology Level, we also test new fixes for the less severe bugs (such as the ealier example of  the typo in the man page), that we found before the Technology Level was released to distribution. Occasionally we also find new, more severe problems that need to be urgently need to be addressed. All of those fixes get included in the first Service Pack.

The near simultaneous release of the first Service Pack is built into our process of releasing a new AIX Technology Level.

By the way, this policy of releasing a fix at the same time as a major AIX update isn’t anything new. Before 2007 we would roll up all of these kind of fixes into something that we called  “The First PTF”. The First PTF would come out the same time as the underlying Maintenance Level. After 2007 we restructured AIX release support and did away with standalone PTFs which is why we now release these fixes as the first Service Pack.

Another “Why” question that has come up recently is:

“I’ve been running an Interim Fix for a problem for some time, but it wasn’t included in the latest Service Pack. Why not?” 

The key thing to understand is that Service Packs are not simply bundles of Interim Fixes. There is a lot more to releasing a Service Pack.

Let’s work though an example:

  1. Let’s say that company XYZ has a problem in AIX
  2. The admin for company XYZ calls IBM Support.
  3. IBM Support investigates the problem and finds that there is a bug in the code.
  4. The Support person crafts an Interim Fix that corrects the problem for that client.

The Interim Fix is specifically targeted at a particular AIX level in that particular client’s environment.  The point of that Interim Fix is to quickly address the problem for a particular client in that client’s specific environment.

The AIX architect responsible for that area will also analyze the bug and the Interim Fix provided as she works on a future Service Pack update. Remember that the Interim Fix for company XYZ that was delivered in step #4 above was tailored for that specific client’s environment. When it becomes time to roll that fix for that bug into the next Service Pack, the architect will look at the Interim Fix in the context of supporting all customers, not just company XYZ.

Sometimes the Interim Fix provided to company XYZ would not be appropriate for other customers. In that case, the architect will have to come up with a fix that would be more generally applicable. Because that process takes some time, that more comprehensive fix may not be delivered in the next Service Pack. Additionally timing and workload issues also affect when fixes get rolled up into a Service Pack. All of these factors may result in a fix not being delivered in the next Service Pack even though it had been made available to a client as an Interim Fix.

I hope this explanation of how we test and roll out AIX Technology Levels and Service Packs has been helpful. If you have other questions about AIX you can post a comment to this blog or drop an email to and I might make it a topic for a future blog post.



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.

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