Stabilizing & Modernizing the Mainframe Platform

Photo by Niklas Ohlrogge on Unsplash

How the CIO organization is building business value with its zSystems

IBM’s CIO organization manages the infrastructure and platforms for IBM’s business. Recently, we have been working to stabilize and modernize our zSystems platform as a core element of our hybrid cloud. You might be wondering why, after 40 years of modernizing IBM’s internal applications, we’re doing this now.

Like many technology environments, changes over years and years often result in outdated architectures and challenges in maintenance while application demands evolve. This leads to short-cuts and sometimes non-ideal configurations and practices to ensure that the business continues to function. In our case, we have a very large number of applications running on a very large number of logical partitions (LPARs), on our Z infrastructure. Combined with old software life cycles, the lack of a modern Z platform approach makes our applications and the infrastructure very to manage.

The CIO organization is working on new platform approach and standards to simplify, stabilize, and improve the operating environment and bring our Z platform in-line with modern practices including zero-down time, software defined infrastructure, and CI/CD pipelines. This will allow the applications to concentrate on providing business value instead of dealing with the legacy infrastructure.

How we’re stabilizing and modernizing zSystems

But what does “stabilize and modernize” mean, given that z/OS and z/VM are already stable and modern platforms? It means we are taking z/OS (and later z/VM) to the next level; functions and operations like we expect in a cloud-native environment. The best of both-worlds from security, availability, and agility for workloads a digital business requires.

That next level of stabilization and modernization refers to the way we build, maintain, upgrade, and integrate z/OS with the applications. We are building the next generation of z/OS implementation, including z/OS-as-a-Service and an automated CI/CD pipeline for z/OS.

Here are the areas we are working on:

1. The z/OS layout, including source control management for all z/OS customizations
2. Full automation of z/OS build, deployment, and test processes using a CI/CD pipeline
3. The way applications interact with z/OS upgrades and newer technologies

z/OS layout

First, we are creating a production environment for all applications with multiple environments that are running multiple versions of z/OS in a single z/OS SYSplex. A z/OSSYSplex is having multiple LPARs or server combined into a single z/OS view for high availability. The single z/OS SYSplex can support up to three current releases of z/OS. Those versions can support multiple versions or releases of subsystems including IBM’s Db2 database, IBM’s IMS (Information Management System) both transaction manager and database, CICS (Customer Information Control System), MQseries (Mesasge Queue) and WebSphere on z/OS.

z/OS automation

Second, we are creating z/OS infrastructure as code and a fully automated CI/CD pipeline to build, deploy, and test z/OS and its subsystems and components. The build process will create a set of z/OS resident volumes (RESvolumes).

The pipeline’s steps are:

1. Run a zResBuild process for RESvolumes based on the YAML selection list for each z/OS version or release
2. Deploy or copy the RESvolumes to the z/OS SYSplex
3. Automate the movement of workload from the LPAR or server which is being upgraded to another LPAR or server
4. Automatically shut down the z/OS LPAR or server after the workload is paused and moved to another LPAR or server
5. Change the initial program load (IPL) volume to the new RESvolume set
6. Fully automate the rebooting or initial program load (IPL) of the LPAR or server
7. Run test cases to verify the IPL was successful

a. If not, repeat the process to restore the old RESvolume set

b.If successful, schedule the next IPL for the next application environment and repeat

The zResBuild is the name of the Python-based script which will perform the following tasks:

1. Re-initializes (INITs) or INITs the RESvolume set
2. Creates IPLtext on the IPL volume of the RESvolume set
3. Runs a series of copy steps to copy the SMP/e target libraries (source) to the RESvolume set (runtime), including:

a. Customized files such as PARMLIB and PROCLIB copied from GitHub

b. Target libraries, PDS (Partitioned Data Set) and PDS/e (Partitioned Data Set extended)

c. zFS (z/OS file system, similar to SAN LUN) files; unmounted, copied, and remounted

Application interactions

Probably the most major change is how the applications interact with z/OS upgrades and newer technologies. To accomplish this, we will have multiple versions of z/OS and subsystems in the application environments.

For example, if an application is running CICS v5.5 under z/OS v2.3, and CICS v5.5 is supported under z/OS v2.4, then the application will be able to shut down its region (automatically, of course) on z/OS v2.3 and start it on z/OS v2.4.

We will also set up standards for when an application wants to upgrade a component, such as a new version of Db2 or IMS, or to increase availability.

Regarding availability, z/OS is working towards seven 9’s (99.99999%) uptime, which equals about three seconds of downtime per year. Applications will also have higher availability options using outlined standards to allow the application to fail over at the application level, not z/OS level from one datacenter to another, run for a time, then switch back. The goal is to provide the least amount of downtime at the application level for the failover.

Increasing the value zSystems for business

We are working to free up the applications from anything that doesn’t contribute to our business goals. At the same time, we will make all the newer technologies, features, and functions available to the applications, so they can upgrade when they need or want to.

In summary, we are adopting a modern approach to building and maintaining z/OS while looking at the design from the application’s point of view. This will allow the applications to exploit all the capabilities z/OS has to offer without waiting for the infrastructure to install, set up, and support the newest features. Ultimately, this approach will allow the application teams to work more on what brings value to the business.

Jerry Edgington is a Z Platform Architect at IBM based in Cincinnati, OH. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.