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 chromeaix@gmail.com and I might make it a topic for a future blog post.

Jay

Advertisements

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.

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