Skip to main content

Updating a Mainframe

I have done systems administration for as long as I remember, and while I have set up countless of services and servers - I have quite limited experience working with the full life-cycle of truly enterprise software. Therefor, I thought it would be interesting to understand more on how one would plan for and execute updates on an IBM Z Series mainframe.
If you consider a typical Linux system you generally have some sort of distribution release number (e.g. Ubuntu 20.04 LTS) as well as maybe a service pack (E.g. 20.04.1). Drilling a bit deeper you have individual packages like Apache2 at a certain version number. As part of keeping the system up to date you would typically have a schedule like the following:
  • Update all packages once every week
  • Update the release once every two years
The service packs in Linux are typically implicit. If you install the latest package updates that means you are up to date on the latest service pack. In Windows the service packs used to be explicit (e.g. Windows XP SP4) but Microsoft has since then adopted so called feature updates that act similar to Linux releases. When you install those feature updates the whole OS is reinstalled as part of those updates, while trying to preserve the data as best as it can.

What about mainframes?

Mainframes work quite similar to what we are used to, but not exactly. This is where the acronyms start. IBM calls software as Licensed Internal Code (LIC). If you see the term LIC you can mentally substitute it for "program", "software", or possibly "firmware". The version of a LIC is referred to as its Control Level (CL). The LIC has releases similar to Linux releases, while the CL is more like service packs.

Example: The Support Elements' (SE) LIC is called "Driver XYZ" where XYZ is the release name. For the z114 the latest LIC release is "Driver 93G" - commonly referred to as just "Driver 93". In my case, the full version I am using is "Driver 93G CL0011" which you now should be able to parse.

Side note: The installation medium for the LIC is commonly referred to as activated read-only memory (AROM). If anyone knows the history behind that naming I would love to hear it!

So far there are next to no differences to a typical system except for the new acronyms and names. That ends here. You would be excused to think that users of CL 1 would update to CL 2 when that is released, it is the logical thing coming from a typical Linux world! However, that is not what you typically do here. The only time you would change the CL is when you do a upgrade to a new release (e.g. Driver 86E CL x to 93G CL y). In fact, if you try to restore a backup to a system on a newer CL it would fail. In practice you install the recommended CL level at the time of the LIC upgrade and you stick with that.

So, what about day-to-day updates?

So if you do not update the CL level, how do you make sure you have all the updates? Unsurprisingly, in a similar fashion as that typical Linux system we keep referring to. A CL is simply a "lower bar" of versions of all packages. If you were to compare CL 1 and CL 10 you would see the same packages but newer versions, no other differences. In fact, a fully updated CL 1 and a fully updated CL 10 will have the identical set of package versions.

Fun note! Knowing that CL 1 and CL 10 when updates contains the same package versions, why is it that you cannot restore a backup? It has to do with the way backups are implemented on the support elements. A backup contains the system modifications since the CL it is running. This means that a system based on CL 1 would have larger backups than systems based on CL 10. Knowing this, it is hopefully easy to see why restoring a CL 1 backup upon a CL 10 might lead to an inconsistent system - which is why I am guessing IBM choose this particular limitation.

So far I have used the term packages - that term is actually not used for IBM LIC updates. They are instead called Engineering Change streams (EC or EC Stream) and are associated with an identification number and a description. The version is also not called version, it is referred to as Microcode Change Level.
An EC number identifies a particular set of internal code that collectively has a common purpose. Within each EC, an MCL identifies a particular internal code change and distinguishes it from previous and subsequent changes (ie. other MCLs) to the same EC. 
Example: The FICON firmware for z114 is called N48123 and has the description "Ficon Express8S LIC". On my z114 I am running MCL 11.

If you ever mess up an update and need to roll an update back, you can always do that from the support element. An EC Stream has four different versions; Retrieved, Installable, Activated, and Accepted. When an update is made effective it is referred to as activated. An activated but not accepted update can be rolled back. When the update is known to be good it can then be accepted to update the known good state to include that particular update. In practice you would accept all currently activated updates when you start a new update. That means that you can always roll back to the last known good state.

With all that explained you should now be able to parse the following dialog. This is the dialog that displays exactly what management software and firmware is running on the mainframe.

If things have gone really bad you can reinstall the support elements and restore from a backup, at which point all firmware and management software will be returned to the known working version. I find that particular fact really nice. In a PC server if you want to downgrade firmware you will likely have to do an ad-hoc process per component (e.g. one for BIOS, one for NIC firmware, etc.).

Closing mentions

There are quite a number of processes I have not covered in details, but they are worth mentioning. So here goes.

Some mainframes have their support elements kept disconnected from the internet for security reasons. When doing an update you then order a SUL (sorry, do not know the acronym!) package from IBM which can be used to install all available updates.

If you do not wish to install a particular update, there are plenty of ways you can select some but not others - that is something that I wish more modern systems would consider. Indeed, this function is part of a critical feature called Concurrent Driver Upgrade (CDU). It works by upgrading to a fixed point but not further. The driver upgrade has been crafted by IBM to support doing hitless upgrades from these CDU points. I can highly recommend the interested reader to read more about this process in the z Series HMC Redbook.

Another important subject are so called High Impact/Pervasive Program Temporary Fix (HIPER) alerts. These are sent out by IBM to inform customers about critical bugs and what updates needs to be installed to work around these issues. This is how an example HIPER looks like:

I asked an IBMer "How often do a typical mainframe customer install the latest updates?". I was not sure what I expected, but the answer was that the recommendation is to do an update every 3 months and is done by an IBM technician. I take this to mean that few if any customers go through the update process themselves.

That is all I had for you folks this time! Since my z114 does not have an IBM support contract my experience running these processes described above is limited. Do you have stories to tell or experiences to share? Let me know down in the comments!

Thanks for reading!


  1. I recently purchased a z114 M05 and I probably have to run some updates on it. Do you know where these updates can be obtained? Also I’m curious what it would take to get a COD code so I can activate and deactivated CP as needed because it’s currently a C02 CPC level.

    1. Hi!

      Capacity-on-Demand is described in some IBM technical journals and it is quite well engineered. My z114 is O03 and I have not been able to convince anyone at IBM to let me buy an upgrade code, so I wouldn't hold my breath sadly.

      For updates you need to either get a maintenance contract or find a SUL disk for your CL level.

      Sorry I can't be of more help.

    2. I am a retired IBM mainframe hardware specialist. I used to service z11`4s. Looking for a house with a bigger basement and garage and I may persue somethng like an old z12.

      I have a DS6800 I got with no DDMs. I used to service these too. It's giving me trouble accepting used DDMs. Do you have any experience with that?

    3. fbrgls77: Yes in matter of fact!
      I managed to get my used drives to work when I found a "Bring online" action in the DSSM interface. It should be under Physical Summary and then Properties. Select to show DDMs and you can select them and should be able to bring them online.


Post a Comment

Popular posts from this blog

Buying an IBM Mainframe

I bought an IBM mainframe for personal use. I am doing this for learning and figuring out how it works. If you are curious about what goes into this process, I hope this post will interest you. I am not the first one by far to do something like this. There are some people on the internet that I know have their own personal mainframes, and I have drawn inspiration from each and every one of them. You should follow them if you are interested in these things: @connorkrukosky @sebastian_wind @faultywarrior @kevinbowling1 This post is about buying an IBM z114 mainframe (picture 1) but should translate well to any of the IBM mainframes from z9 to z14. Picture 1: An IBM z114 mainframe in all its glory Source: IBM What to expect of the process Buying a mainframe takes time. I never spent so much time on a purchase before. In fact - I purchased my first apartment with probably less planning and research. Compared to buying an apartment you have no guard rails. You are left

Brocade Fabric OS downloads

Fabric OS is what runs on the SAN switches I will be using for the mainframe. It has a bit of annoying upgrade path as the guldmyr blog can attest to. TL;DR is that you need to do minor upgrades (6.3 -> 6.4 -> 7.0 -> ... > 7.4) which requires you to get all  Fabric OS images for those versions. Not always easy. So, let's make it a bit easier. Hopefully this will not end up with the links being taken down, but at least it helped somebody I hope. These downloads worked for me and are hash-verified when I could find a hash to verify against. Use at your own risk etc. The URLs are: ftp://ftp.hp.c

System z on contemporary zLinux

IBM System z supports a handful of operating systems; z/VM, z/VSE, z/OS, z/TPF, and finally zLinux. All the earlier mentioned OSes are proprietary except for zLinux which is simply Linux with a fancy z in the name. zLinux is the term used to describe a Linux distribution compiled for S390 (31 bit) or S390X (64 bit). As we are talking about modern mainframes I will not be discussing S390, only S390X. There is a comfortable amount of distributions that support S390X - more or less all of the popular distributions do. In this  list  we find distributions like Debian, Ubuntu, Gentoo, Fedora, and RHEL. Noticeably Arch is missing but then again they only have an official port for x86-64. This is great - this means that we could download the latest Ubuntu, boot the DVD, and be up and running in no time, right? Well, sadly no. The devil is, as always, in the details. When compiling high level code like C/C++/Go the compiler needs to select an instruction set to use for the compiled binar