Application Modernization

Migration, Modernization, Re-Architecture

The whole notion of maintaining and improving the application inventory of a firm, institution, or an agency is driven by the core business processes and requirements of the enterprise. Evangelists, Technologists, and even internal organizations can push for new technologies and approaches. There are many competing for both the attention and the revenues.

COBOLworx believes that COBOL will be central to the application inventory of those enterprises that have traditionally used it. And as such, COBOLworx is respectful of the challenges they face.

However computer users at large choose to address the pressures of the future, COBOLworx is convinced that a first-tier COBOL compiler on Open Systems is a valuable potential tool. We are happy to assist with analysis of code holdings, evaluation of recompilation costs and timelines or in any other way we can be of value.

COBOL to COBOL

We consider the notion of machine translation of well-written COBOL source code into well-written source code of another language beyond current technical capabilities. There are at least a few COBOL translators to Java and, to the best of our knowledge, the Java code is by no means as readable or maintainable as the original.

Compiling COBOL from, say, the mainframe to run on Linux is much more direct. The resulting source code has not been materially changed, if at all.

This is also true of compiling COBOL from earlier proprietary distributed systems COBOL compilers to GCC COBOL.

It seems obvious to us that taking this step on the way to more disruptive changes would be a good plan.

A Word on “Getting Off The Mainframe”

COBOLworx’s experience tells us that as big a challenge as the COBOL is, it is one of many. The IBM mainframe is evolving towards modern tools and approaches. The COBOL applications are all wrapped up with legacy control, tools, and transaction processing applications. There are still programs written in ASSEMBLER which force users to remain on the 60 year-old 24-bit addressing of the original System/360.

There should be a layer of COBOL applications that are minimally entangled in the legacy road-blocks. There are certainly Open Systems replacements for some of it. The rest, as potentially valuable it might be to move them to more cost effective platforms, represent a likely larger project than the COBOL itself.

And About “The COBOL Skills Gap”

COBOL is a domain-specific language. Almost every other programming language has followed the lead of general-purpose languages. And they have adopted the preferred representation style of Computer Science. This has been hailed and generally adopted and only the COBOL program inventory is written in a language designed to be understood and critiqued by people with no deep understanding of computers.

COBOLworx has experience putting experienced developers with no prior COBOL experience into a COBOL project. The learning curve is short because the logic is explained on the surface of the code in English. Typically, the new person was productive in a day or two though they had more to learn.

Undergraduate business schools used to teach COBOL. Some university Comput Science programs taught it. But as the Distributed Systems, C, UNIX/Linux concepts were popularized, those courses were dropped. Business was hiring for new skills and relying on existing resources. Now the COBOL and mainframe people are retiring out. And there are hundreds of billions of production lines of code out there needing attention.

As the need becomes more acute, demand for training will, in our opinion, return and the skills mix will balance out.