Oct 28 ’14

Linux on System z: Taking off or Stuck at the Airport?

by Andrew Chapman in Enterprise Tech Journal

I started working on the mainframe less than two years ago and immediately recognized that System z offered a technically superior platform for deploying Linux when compared with many distributed systems. Nearly two years later the deployment level of Linux on the mainframe has remained largely static; certainly we have not seen the growth that you’d expect of a technology that underpins a high-growth space such as the cloud.

As we struggled to reconcile the anecdotal evidence from our customers with the information posited by vendors in the space, CA recently embarked on a concentrated effort to examine our customers’ use (or lack thereof) of Linux on System z.

We decided to do some product management 101 fact-finding, consisting of a number of online polls and interviews with advocates, opponents and moderates. We wanted to determine when customers elected to use System z as a platform, the compelling events behind those decisions and roadblocks to more deployments. The results are incorporated in Figure 1.

We mapped the typical Linux on System z workload on a graph showing the internal “resistance” to deploying Linux on System z against the size of the addressable market. We found five broad workload categories, which we mapped to the chart, discussed below.

Supporting Internal Mainframe Systems

In the first column we see Linux workloads that exist to offload billable MIPs from z/OS. In all cases, there was little resistance from the enterprise IT group because they typically were not even aware that these workloads existed. Even when they were informed, they could not make a coherent argument that these workloads should be moved off the platform.

Typically, these guests are very limited in number and complexity. They are not supporting high-growth areas such as the cloud so they will scale only as General Processor (GP) MIPs scale, and that’s painfully slow.

Benefiting From Proximity to z/OS

This category was very similar to the first one but with independent applications that make heavy use of a z/OS system and benefit from a direct connection. In theory, you could deploy these workloads off the platform but they are so mainframe-centric that the work involved in moving them would discourage most enterprise operations teams. Once again, though, these workloads are almost entirely tied to the scale of the underlying/OS systems and are, hence, small and unlikely to grow at any speed.

Offloading z/OS Workloads

In the middle column, we start to see systems that could potentially be migrated off the platform but because they originated on z/OS, the System z team has a seat at the table to discuss the most appropriate platform. In this case, the resistance from the enterprise team was higher and the opportunities for Linux larger. That said, these workloads are still z/OS-oriented and are growing at a substantially lower rate than other areas of Linux.

Inheriting Mainframe Qualify of Service

In this column, we start to see workloads that may have originated on a distributed platform: These workloads may have nothing to do with z/OS at all. The rationale for using System z is that the customer wants to inherit some of the attributes of the mainframe. Most typically, this is disaster recovery, high availability or security, but might also include a need to consolidate servers to conserve data center space and reduce those associated costs.

The quantity, variety and complexity of these workloads are vastly higher than the previous three categories. Alas, so is the resistance to using System z as the platform of choice. Working out how to be more successful in this space will lead to significant success for Linux on System z. This is the target category that we usually think of when talking about “fit for purpose” decisions.

Implementing Enterprise and Cloud Linux Workloads

The final frontier in Linux deployment would be the general acceptance that the mainframe is a viable platform for any or all Linux applications. Organizations that have selected System z as the primary deployment platform and use it in this way definitely yield the greatest savings.


In a future article, I will highlight our conclusions for how we can remove barriers to increasing the deployments in categories four and five and how to create compelling events to encourage adoption. For now, it is essential that the System z community recognize there’s not only a big difference in the issues encountered, but also in the size of the potential market.