LzLabs: source code dependency dragged down mainframe rehosting, until now

Cresswell writes…

The halcyon days of mainframe application development started in the 1970s and continued until the arrival of distributed computing in the early 1990s. It was during this period that most mainframe applications, which still form the backbone of over 70% of the world’s electronic commerce, were originally written.

Few programmers who developed these applications thought their work would still be in use in the year 2000, let alone 50 years later.

Source code management in these pioneering days relied heavily on local system knowledge. The source code management disciplines we take for granted today only became part of the application development lifecycle as the job market for programmers exploded, and staff turnover increased.

The loose relationship between source code, documentation and the actual programs in use, has been a developing problem for half a century. Whilst businesses in all manner of industries are increasingly looking to rehost mainframe applications in modern Linux environments in order to achieve cost savings and agility, the difficulty in identifying precisely which source code was used to build aspects of long-running applications is central to some of the challenges of these rehosting projects.

Unravelling source code dependencies

Without an application dependency map, which is often missing from legacy mainframe application documentation, users must undertake the arduous task of identifying which other applications and files the target application depends on before they can confidently approach rehosting it off the mainframe.

Once a user starts looking, it is very common for a list of program dependencies to grow exponentially. The initial program may reference two others, which may in turn reference another two, one of which may be called by other programs. The files used by the first program may also be used by an entirely different set of programs, all of which have their own dependencies.

This Gordian knot of interconnections can exponentially extend the scope and duration of workload rehosting projects beyond all forecasts

When the rehosting strategy is based on recompilation of source code, the situation becomes dramatically worse. For each program, the source code and any copybooks must be found.

As an IT executive in one large enterprise lamented, “We’ve got about 100 million lines of COBOL in our source code repository, but it’s OK as we only have 10 million lines active. We just don’t know which 10 million.”

To consider recompiling such applications to run on a new platform requires the daunting task of correctly identifying all the active source code, and making it available for migration.

Also, some early mainframe programs simply cannot be compiled to run on modern architectures. Such programs were written during a time when no one cared about the lock-in caused by direct reference to underlying system level functions such as operating system control blocks and unique file implementations. There are a surprising number of these programming needles in many organisations’ application portfolio haystacks.

However, source code availability is far from the only issue at play when looking at rehosting mainframe workloads. The way in which the operating environment was implemented, and has evolved over more than half a century, has resulted in fundamental differences in mainframe encoding, collation and database processing models that cannot be recompiled away. Stated differently, even if the source code is available, insurmountable problems remain. But this is a story for another time.

The solution?

The above paints a rather bleak picture of the challenge facing organisations who are desperate to liberate their legacy applications. Until now, businesses have seen no feasible way to run these old applications on newer hardware which appears on the surface to be entirely incompatible.

But what if a legacy mainframe application could be rehosted without the need to find, or even worry about the source code – without recompilation?

This is where the concept of a Software Defined Mainframe (SDM) comes in.

(Ed — this is a bit of shameless plug, but as it in context and… the wider context of this piece has developer reader value and it’s in context, then is it permissible.)

SDM makes application rehosting possible by making certain mainframe specific features available to applications. Using this approach, applications and associated data can be moved, with no reformatting, or requirement for original source code. Using other methods, the program migration would require time-consuming, risky and expensive rewrites, recompilation and extensive regression testing.

Modern Linux + legacy

Yet, even in this modern Linux environment, there is no escaping the need to work with some of the legacy source code. Many mainframe applications are regularly updated for business or regulatory changes.

However, an SDM enables ongoing development using modern tools. Graphical development environments; modern source-code management and DevOps processes and toolchains, make ongoing legacy application maintenance far easier, and open to a younger generation of programmers.

Mainframe workload rehosting is increasingly popular, but the legacy of 50 years of mainframe programming has created a bewildering array of barriers to success for any project that relies on source code – barriers made insurmountable by the mainframe skills shortage. With an SDM approach, we’re seeing the first low-risk, practical option to enable businesses to continue to use their investments in legacy application software as part of modern strategies.

LzLabs’ offices in Switzerland and the UK – you can reference the firm’s website here.

LzLabs Cresswell: today, people care about lock-in… and we’re fixing that.