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.

For the entire life of z/OS, over 50 years, the operating system has relied on skilled assembler programmers to maintain and enhance the system.  Assembler skills are still almost required to initially configure and customize z/OS.  This is true for doing things like specifying the separator page on print out, coding up a logo for the logon screen, or time setting limits.

In the last couple releases we have begun to introduce capability that allows customization without requiring assembler skill.  This includes introducing policy based parmlib support such as SMFLIMxx which lets you set many of the memory limits in z/OS using a declarative style rather than having to code assembler.  This parmlib member got a little smarter in z/OS 2.4, we also added support for some of the RACF requirements for assembler code in z/OS 2.3 and we are planning to support a general policy based facility in JES2 in z/OS 2.4.  None of these mechanisms remove the existing assembler exits but instead provide you with an alternate way to specify some of the more common items.

The idea being that one should eventually be able to administer a z/OS system without requiring assembler programming skills.  But there is still a need to be able to extend the operating system by our independent software vendors.  In that case we are also concerned about the ongoing assembler skill and to that end have begun shipping C header files for common z/OS control blocks.  This support is available starting in z/OS 2.4 and ships the headers in both a PDS dataset as well as in the zFS file system.  Initially in z/OS 2.4 we are shipping a subset of headers that will cover SMF records and some system data areas.  Over time we would hope to be able to expand that to more of the mapping macros shipped in SYS1.MACLIB and SYS1.MODGEN.

I’d be interested in knowing if our approach of reducing assembler skill requirements is something that you see value in.

Several releases back z/OS JES2 introduced the job correlator.  This is a string that can be used for several things.  First it acts as a longer jobname.  When you submit a job with the job correlator you can select up to 32 characters additional data to be added to the job.  You can select a job or query it by correlator.  You pick a name and then you select by that name.

JES2 will carry the name in the spool structures for the job and you can either continue to look for the jobname and optionally the jobnumber… or you can do a query using the correlator.  It is your responsibility to make the correlator unique if that is a requirement you have.  This is reasonably easy… generate a name, query for the name and if not found it is unique.

This can be particularly useful if you have your own job scheduling package and you want to be able to generate your own job naming and locate the jobs yourself.

The job correlator is also queryable in SDSF, as well as through the z/OSMF REST JOBs API and of course the normal assembler subsystem interface (SSI) of z/OS.

To specify the job correlator you can modify the batch job and add UJOBCORR= on the job card to the value you want.  If you don’t want to modify the job, you can specify the JES symbol SYS_CORR_USRDATA on the invocation of the internal reader DD statement of the submitting address space.  The z/OSMF REST JOBs API can also assist with that.

Have you ever used the job correlator?

For most z/OS system programmers one of the “goto” tools is SDSF.  Some have said a day doesn’t go by without them going into SDSF.  For many non-system programmers they also have access to SDSF but often a small general use subset.  The SDSF user interface is available in a 3270 (green screen) form as well as in a browser based format in z/OSMF.  There is also a REXX programming interface that is heavily used and a much less used JAVA programming API.

Being able to see the processes (address spaces) and what they are doing (DA – Display Active), what resources they are consuming, is a key feature of SDSF.  This data is displayed in tabular form and can be sorted, filtered and otherwise manipulated.  But you can also look at the queues of work arriving and waiting to run (I – Input), work that has completed(S – Status), and the output that work produced as it is waiting to be processed (often printed, using O – Output).   There is a special queue for output or jobs that have completed but are ‘held’ meaning they are there to be seen on request (H – Held).   This was arguably the first thing that the SDSF product showed and is also what most operations and developers use.

Beyond seeing the data you can also manipulate the data.  For example you can see a held job and if you want to get rid of it you can purge it with a single keystroke.  You can also print output if and delete it or even print it and keep it in the held queue.  One the coolest things is SJ, which allows you to look at a job, get the JCL back and edit it and resubmit it.

Beyond this kind of work SDSF lets you look at many other parts of z/OS.  One of my favorite commands is the SYS command which will give you a LOT of information about the system.  If you are running in a sysplex then the SYS command will display one row per system and you can compare them.  There are many more detailed subcommands under SYS that can show you more detail.

In recent releases of SDSF there have been many new primary commands added which you may or may not have access to.  The main menu is a scrollable menu and there are options to show or hide options that you don’t have access to.

What is your favorite part of SDSF?  Do you have suggestions for new capability?  Leave a comment…

z/OS 2.4 which was previewed in February of 2019 contains a new feature called Container Extensions.  It is entitled with z/OS 2.4 which means it is part of the z/OS deliverable.  It gives you the ability to run any Linux on z Docker container on z/OS.  It runs in a started task in an address space just like any other middleware service on z/OS.  This means it fits into your existing system without requiring the definition of a new LPAR (logical partition) and can use the hardware that the existing z/OS is using.  This means you don’t need to define new networking hardware, or new disk.

You can read more about it here – https://www.ibm.com/support/z-content-solutions/container-extensions/

I made a short video here https://youtu.be/xOuoTqaBqqU

There is also a podcast here http://terminaltalk.net/PodcastGenerator/?name=gary_puchkoff_-_z_os_container_extensions.mp3

A couple articles as well http://ibmsystemsmag.com/mainframe/trends/z-os/z-cx/ and http://ibmsystemsmag.com/mainframe/hot-topics/container-extensions-faq/

I will write more about z/OS 2.4 once we announce the GA.

If you haven’t seen it ICBC one of the largest banks in the world recently created a really positive customer reference for z/OS 2.3.

https://www.ibm.com/case-studies/industrial-and-commercial-bank-of-china-systems-software-mainframe-z

As we will discuss in a later blog, this customer has a lot of good things to say about z/OSMF.