Dan's Take

Applying 'Software Defined' to Mainframes

A breakthrough or marketing hype? Analyzing a startup's claims.

• By Dan Kusnetzky
• 05/30/2017

Representatives of LzLabs reached out to me to wave a banner for the company's "very first customer," Swiss telco and IT service provider, Swisscom. According to the company, their customer is "planning to migrate its mainframe applications from its IBM mainframe onto x86 servers running Linux, using the LzLabs Software Defined Mainframe."

I also suspect that they reached out to me because of my earlier articles on mainframe workload migration. After reading through the release, I'm finding myself feeling rather skeptical.

The catch phrase "software defined mainframe" caught my eye and I thought the concept was worth discussing. What do you suppose does the phrase means?

Here's how the company describes its concept:

"Using the solution, Swisscom will run existing mainframe applications on more cost-efficient Linux servers, without changes to its application program code.

The re-hosting requires no recompilation of COBOL or PL / 1 application programs as LzLabs supports existing mainframe operational environments and programming languages. As a result, Swisscom will reduce the high recurring costs of its mainframe software and hardware licensing, while retaining the value of its extensive investment in old software applications, data and business processes.

Operating as part of Swisscom's core IT infrastructure, The Software Defined Mainframe runs as a virtual system within Swisscom data centres in Switzerland, using standard x86 servers running Red Hat Enterprise Linux. By moving to the LzLabs Software Defined Mainframe, Swisscom is using its mainframe as a converged / engineered solution (computing, storage, databases and other IT infrastructure functions) for enterprise applications such as online and batch processing."

At first take, the concept "software defined mainframe" would imply that somehow an entire mainframe computing environment could be encapsulated, and would execute, in a virtual environment. Furthermore, this encapsulated environment would be agile and could be easily migrated from one physical system to another, one datacenter to another, or move both off- and on-premises as required with no changes to the applications or workload management functions. I don't believe that LzLabs' view of the concept is quite as broad or all encompassing.

I do know of a company, Transitive, which had figured out a way to develop x86-focused virtual machine (VM) technology that allowed mainframe binaries to run unchanged.  Had this technology become broadly available, the industry debate concerning mainframe migrations would have become a moot point.

Their approach would have allowed an entire mainframe computing environment to execute in a VM on X86-based systems. I would expect that IBM would not have licensed its mainframe OS, database or language processing tools to execute in this computing environment.

Transitive, by the way, was behind Apple's technology that allowed Motorola-architecture Mac applications to execute on Apple's then-new x86 Macs. It was also behind the products HP and IBM offered to move SPARC/Solaris Code to either HP Precision architecture machines executing HP-UX, or IBM Power architecture machines executing AIX.

IBM acquired Transitive back in November 2008 and its technology disappeared. It's worth noting that those other uses of the technology disappeared shortly thereafter.

If we deconstruct the announcement, the following tidbits emerge:

• This is the first customer that has taken up LzLabs on its "software defined mainframe" concept.
• The customer hasn't really migrated any mainframe workloads at the moment, it is just planning to take up that task.
• It appears that the technology is focused on migrating COBOL and PL/I applications to a Java-based computing environment, and really doesn't address the very broad portfolio of tools and languages required to completely address all of the needs of a mainframe computing environment (see The Ongoing Quest to Migrate Mainframe Workloads to see what an enormous task that really is).
• It appears that the technology behind this concept is the result of an acquisition of intellectual property rights to tools allowing COBOL to Java migration from Eranea. One would also believe that Eranea's technology has been extended to allow PL/I code to be migrated to Java as well.
• It's not at all clear that applications and workloads optimized for a compiled mainframe computing environment are going to work as well, scale as well or be as well optimized for an environment based upon Java's incremental compiler and Java virtual machine.

Customers are likely to be forced to do a great deal of experimentation to determine how many Linux physical and virtual systems will be necessary to support the mainframe workloads, and whether there will be a cost savings at all. It's also not clear if the environment will scale as well as a mainframe computing environment.

Another potential issue: it's not at all clear whether more complex, multi-language, multi-database workloads will execute in this environment. I see no mention of workload management, job control language translation or provision for migration of the data from the many database management systems that live in a mainframe computing environment. LzLabs may be offering tools that address this issue; it just isn't clear from the announcement materials.

It's also not at all clear whether third parties will support their products in this computing environment, if the code being migrated came from a third party. If not, LzLabs' customers are likely to find themselves having to recreate needed tools, utilities, communications products and the like. I'm hoping to learn more about the "software defined mainframe" concept to determine if this falls into the "buzzword compliant marketing" or "bright idea" category.