Dan's Take

A Second Look at LzLabs' Mainframe Migration

Diving deeper brings additional clarity.

• By Dan Kusnetzky
• 06/28/2017

LzLabs reached out to discuss my article, "Applying 'Software Defined' to Mainframes." They thought the article didn't fully capture what they were doing, and wanted to provide a more detailed explanation of their mainframe application migration product, the Software-Defined Mainframe (SDM). I must admit that I was far more impressed with what the company was doing after our conversation.

As I pointed out in the previous article, mainframe workloads are often complex mixes of COBOL, Assembler, the Job Control Language (JCL), a transaction processing monitor such as CICS, and one of several mainframe database engines. Migration of an entire workload typically includes finding a way to replace:

• The workload management functions defined within the JCL files
• The transaction processing environment supported by CICS or IMS TP
• The database engine, which could be Adabas, CA Datacom, IDMS, Oracle, FOCUS, NOMAD, TOTAL/SUPRA/ULTRA, IBM IMS, Model 204, SQL/DS or others
• Applications written in Assembler, Basic, C/C++, CLIST, CSP, COBOL, FORTRAN, Java, Pascal, PL/I, Python, QMF, REXX, Ruby, PERL, RPG, and even Smalltalk! If one looked hard enough, I bet even a few APL and MUMPS programs could be found

After my conversation with LzLabs, it's clear that they understand how complex the computing environment can be, and choosing to address a specific segment of mainframe migration in a straightforward, pragmatic way rather than trying to do everything for everyone all at once. Moving a single or small number of applications is a much more obtainable goal.

Smaller Goals
LzLabs developed SDM; it basically compiles mainframe load images and produces code that executes on industry-standard x86-based machines running Linux. No IBM software is required for the migrated application to function in its new home.

Currently, the company is focused on moving applications that "rely upon COBOL, PL/I, CICI and IMS, not taking down the mainframe." This means that they would advise customers relying on complex workloads made up of hundreds or even thousands of applications linked together by complex workload management functions to leave them where they are, i.e. on the mainframe.

Enterprises aren't forced to delve into the code that produced the load module unless they want to change the program.  SDM can gobble up a mainframe load image and produce a Linux executable. If the application needs updating in the future, LzLabs advises customers to first update the code on the mainframe, make sure it works, and only then deploy SDM to migrate the load image.

This means that enterprises would find it straightforward to "pluck" a small number of simple applications off of the mainframe and move them to an environment having lower hardware, software and service costs. LzLabs' goal is make it possible to move an application and have it "just work" on the other side.

LzLabs believes that if enterprises inventory their working applications, they may discover that it's possible to move a few hundred applications; the result would be a significant savings on hardware, software and services. The company planned to address the market for enterprises wanting to offload some mainframe applications; not to address the requirements some have to move everything all at once.

Dan's Take: Impressive, Focused Technology
LzLabs has developed some very impressive technology that can take mainframe load modules and recompile them into Linux images. Unlike some of their competitors, such as COBOL-IT or TmaxSoft,  LzLabs' technology doesn't focus on moving COBOL workloads by translating mainframe COBOL source code into Java or source code for another COBOL language processor available on Linux.

Although at first it appeared that the company was trying to be everything to everyone everywhere always, what I've learned is that they are, instead, tightly focused on a task that they can complete; it's a task that would be useful to a select group of mainframe customers. The company knows that what it's currently doing isn't an answer for everyone, but rather an answer for a sizable chunk of the mainframe market.