We have all heard that saying about an old dog that cannot learn any new tricks. It is valid for dogs and often true in other cases not involving dogs. Here, we’ll tell one point where it is not valid.
The old dog is the IBM mainframe lately known as IBM Z and this dog is 58 years old. Let’s first state some well-known facts about it.
The birth of the IBM mainframe is marked in the year 1964 when IBM announced the model System/360. It was the first family of computers designed to cover a wide variety of applications. A general purpose computer, rather than a special purpose build device. One of the famous characteristics of mainframe technology is that applications that are written and compiled 50 years ago can still run today. Although many predicted the end of the mainframe a long time ago, today still the largest world banks, insurers, airlines, retailers and other big companies run on IBM Z. It is everywhere. Whatever digital transaction you make, it is likely it will end up touching a mainframe somewhere.
Why this old dog is still here and what makes it strong?
It can run all day, it can wrestle with big bears and it will guard your house 24/7. In other words:
- it can run millions of subsecond transactions concurrently
- at the same time, it can run long batch jobs that are I/O and CPU intensive
- it is resilient and will run for years without a need to restart it
- it is secure
What are the new tricks that it learned?
Not that IBM Z is still used but there is also a lot of knowledge, innovations, hours, and money invested to make it still relevant today. It is still the same at its core (hence the possibility of still running 50-year-old programs) but there are a lot of new features that make it easy to integrate it into modern IT landscapes where it will fit as any other server or device.
One new trick it learned is related to DevOps. Its principles and methodologies are helping increase the speed of introducing new features of applications and services and if an enterprise wants to implement it and the mainframe application landscape needs to be included, no problem. There are tools that make it possible to include the mainframe in an operational paradigm based on DevOps practice. Tools like IBM Developer for Z, Dependency Base Build, and UrbanCode Deploy for z/OS will make the backbone for DevOps pipelines on COBOL, PL/I, or any other legacy application language.
Another new trick is called OpenShift. Yes, you can run it on IBM Z. You can run it on Linux on Z like on any other Linux on distributed platforms. But what is maybe more exciting is that you can run OpenShift inside z/OS using zCX for OpenShift. zCX enables the development and deployment of containerized applications inside z/OS where it can work closely with other legacy applications running in CICS or IMS DC and accessing legacy data in Db2 or IMS databases.
More tricks? Ansible is a very popular tool for the automation of almost everything related to applications and system infrastructure. On z/OS you can connect it to existing JCL or REXX scripts and automate your z/OS environment. Using Ansible on z/OS you can enable a common approach to hybrid applications and infrastructure management and integrate IBM Z into an enterprise automation strategy in a consistent way.
One trick that is pretty cool is Zowe. Zowe is an open-source software framework for z/OS, providing interoperability and scalability among products from multiple vendors through the Open Mainframe Project. Zowe provides a modern application development framework that includes a virtual desktop. Zowe also includes a VS Code extension, CLI and scripting, and an API mediation layer — all of which aid your efforts to modernize mainframe development and support mainframe DevOps. Zowe brings the possibility to develop modern interfaces to z/OS thus making it more attractive to younger generations and allowing them to work with z/OS in a similar way as on any cloud platform today.
z/OSMF (z/OS Management Facility) is complementary to Zowe. It is now part of z/OS and many tasks that are essential to administering z/OS (like SMP/E) are moved to z/OSMF. It’s a framework that provides simplified, streamlined, and automated tasks which system programmers can use during day-to-day operations.
With the growing complexity of the application landscape paired with shrinking mainframe skills, effective tools are needed to manage the z/OS production environment and quickly find and react to any issues. This is where AIOps comes into the picture. Of course, it is not unique to the mainframe but with all those SMF records that you have at your disposal it is just a matter of putting that (together with other useful data) into an AI machine and you can get great help in detecting any anomalies, finding root causes and monitoring your z/OS environment. There are a set of IBM products that can help but there are also other tools that can be used to feed z/OS data into your own AI solution. The very recent one and very interesting is SMF Explorer, just to name one.
Lastly, we need to mention a couple of modern languages widely used on distributed platforms that can also run on z/OS. Java is given since it is present on z/OS for a long time now. To be able to run Python on z/OS you need IBM Open Enterprise SDK for Python. If you think you can use the advantages of Go language you need IBM Open Enterprise SDK for Go. There will probably be more soon.
All the tricks mentioned above help this old dog to stay fresh and vital. They also make IBM Z more attractive to young generations which is crucial for the platform to overcome the big problem of shrinking mainframe skills and to stay relevant.
CROZ mainframe team is doing both as making the team younger by bringing new students on board and also working with those new tricks to be able to get a great time with the old dog.
At the very end, I’d like to point to an old trick that is still relevant today. It is called “Grandma’s recipe for system programmers”.
My dear and very experienced colleague likes to tell the story about his grandma and her way of using eggs to make a cake. She used two cupcakes: one small and one big. She would break every egg first into the small cupcake, check that it is good and then pour it into the big cupcake. That way she avoided mixing bad eggs with good ones.
That is exactly what my colleague thought other members of my team (including me) how to install new software or apply new service PTFs on the system. We always insist to have a separate z/OS LPAR that is the same as production only without any applications or data. There we can install new software or PTFs and test that everything is working on the system level before the same would be done on production and other more important z/OS environments. And we sleep well because of it.
