z/OS Container Extensions has continued to demonstrate our vision of being able to run Linux applications on z/OS. Our first customer is in production with Service Management Unite – SMU. Let me give you a brief outline of why that is so important.

For many years when a group was developing code that was truly platform neutral they would exclude z/OS. Why… well because z/OS is EBCDIC encoding, it implements some Unix functions in a compliant way but different from Linux or Windows, it can be hard to locate a z/OS machine to do development and testing etc.

Our Unix branded facility called Unix System Services was a faithful implementation of the POSIX standard, but the posix standard isn’t everything you need to implement to be the same as Linux. To be fair we have had a lot of very successful ports of applications from other Unix platforms to z/OS.

With zCX, we have a Linux operating system running right inside a z/OS address space. It is close by in the sense that the TCP/IP communication is low latency and high performance because we move data using cross memory instructions. Operationally it is just like any other started task, you start and stop these with operator commands. That means that your automation can easily control the zCX servers.

Service Management Unite is a product that produces a dashboard on top of select IBM systems management products. The SMU implementation uses sockets to gather information about the systems it is displaying. It was written to a Linux platform programming model. The team that owns it in IBM had made it work on Linux x86 and Linux on z. To run SMU on z/OS’s zCX they merely had to create a docker image and bring it over. It runs in a binary compatible manner.

The customer used SMU on a Linux x86 platform. They say that it took them some time to get the SMU server defined by the distributed team and setup so that the communication worked and was secure. It was not the worst experience they ever had, but they did notice a lack of interest from the folks running the x86 platform with their server. It was the last to get security updates, and during disaster recovery it was one of the last to be recovered. As a consequence the z/OS team was less reliant on it.

The move to zCX did a couple things. One was that the z/OS team runs the SMU servers. There are two servers on two systems in a sysplex for redundancy. Further it was very easy to define the data used by the zCX servers or replicated volumes. The SMU server is now recovered with the rest of the sysplex and started again as part of it. The team can rely more heavily on it now.

To my mind this is just one of the many new uses that zCX brings to z/OS, I look forward to outlining some of the other ones in a future posting.

Earlier this week the z15 announced.  This is the latest z processor and is some 14% faster than the prior machine.  It also has a new compression engine built right into the chip, so you no longer need PCI compression cards.  The new compression engine is even faster with improved bandwidth, reduced latency and improved compression algorithms.  z/OS 2.4 of course supports the z15.

Another key item in z/OS 2.4 which I worked on was the System Recovery Boost capability.  What is key here is that when you roll-in a z15 you will get this new capability by default.  There are controls to disable it should you choose to… but the base feature is enabled by default.  What it does it applies a healthy amount of CPU boost for both shutdown and startup of z/OS.

Lets imagine a scenario where you have a planned maintenance window.  You go through your normal shutdown procedure, to indicate that you are shutting down we have a new PROC which you invoke, that turns on the boost.  The LPAR shuts down and then you IPL and during early IPL we apply the boost.  The shutdown boost is 30 minutes and the IPL boost is an hour.  This should give you plenty of time to shutdown and re-ipl.  The expectation is that any part of IPL or shutdown that is CPU limited would find more CPU available and be accelerated.

What are we really doing… 1) we give your cpu’s full capacity during the boost even if you only have a sub-capacity machine,  2) we will allow non-zIIP work to run on ziip’s during the boost, and 3) we improved the commands and sequences for GDPS LPAR during the shutdown and startup.  In the lab environment we saw 2.5x improvement in elapsed time for this processing.  In some cases it can be much more.

This is an industry exclusive and I am proud to have been a contributor to this effort.  If you get a chance to use a z15 I would be interested in your experiences, post them here.