Automated Testing

Wouldn’t it be great if you could take legacy mainframe apps and convert them to a modern language with the click of a button?

Good news: You can – although there are some important caveats that come with using automated tools to convert code written in languages like Fortran and COBOL into modern ones. The conversion process almost always requires more work than just clicking a button, and there are security and code management issues to think about, too.

This article unpacks these challenges to explain what mainframe code conversion tools can, and can’t, do well, and when it does or doesn’t make sense to use them.

What is automated mainframe code conversion?

Automated mainframe code conversion is the process of automatically converting code written in a “legacy” language, such as Fortran or COBOL, to a “modern” one, like Java or C.

I put “legacy” and “modern” in quotes because languages like Fortran and COBOL are not, of course, necessarily consigned to legacy development purposes. There remain plenty of good reasons to continue to write code in these languages today. Not every mainframe application needs to be rewritten in a newer, hipper language.

That said, it sometimes makes sense to convert an older mainframe app to a more modern language. A business may no longer have programmers on staff who know how to maintain legacy code, for example, or it might want to use development or observability tools that don’t support older languages. Replatforming or rehosting mainframe applications could also require converting code to a new language. 

In situations like these, automated mainframe code conversion tools can save developers a lot of time and tedium. By converting code automatically, they eliminate the need to rewrite applications from scratch, line-by-line, in a new language – an effort that could take years if it involves a large codebase.

In addition, automated conversion tools may reduce the level of expertise necessary to perform code conversion, because developers typically don’t need mastery of both the source and target languages to use the tools. Working knowledge is good enough.

A third benefit of converting mainframe code automatically is that it tends to produce more consistent code than a manual conversion process. If you ask multiple developers to convert code by hand (which you would probably need to do if you have a large codebase, because it would be too much work for a single programmer to convert it all), you’re likely to end up with different styles of code in the rewritten app because each programmer will work differently. But with an automated conversion tool, all of your code gets converted in the same way, for better or for worse.

Where to find automated code conversion tools for mainframes

A variety of code conversion tools that focus on mainframe software are available today.

Some are free and open source. For example, you can find a Fortran-to-C++ converter and Fortran-to-Julia converter on GitHub. These tools are easy to access and they cost nothing, but they may be a bit rough around the edges.

For a smoother experience – albeit one that comes with a price tag – companies like Modern Systems and Asysco offer commercial conversion tools that tend to be a bit more user-friendly. Some of them also support multiple source and target languages, which is typically not the case for open-source conversion tools.

How well does automated code conversion work?

How reliable and effective is automated code conversion for mainframe apps? The answer is that it depends.

In some cases, the tool developers themselves warn that the code created through automated conversion “may or may not compile,” as the authors of the Fortran-to-C++ converter put it. And even if the code clears the minimum hurdle of compiling, it may contain security issues, and it’s likely not optimized to achieve the best possible conversion.

Commercial conversion solutions tend to offer more reassuring promises about the quality of the code they generate. But that’s partly because the vendors behind these tools sell not just the tools themselves, but also a hand-holding process through which they help customers plan and configure the conversion process before actually performing it. Planning ahead, and tailoring the conversion process to the specific needs of the project in question, helps to produce a better result. But it also increases the time required to complete the conversion process and the effort that developers have to put into it, at least upfront.

When – and when not – to convert mainframe code automatically

So, should you turn to an automated conversion tool to convert your mainframe code? The answer is probably “yes” if any of the following statements are true:

  • You have a lot of code to convert – at least ten thousand lines, if not hundreds of thousands – and converting it by hand is just not practical.
  • Your application is written in neat, standardized code currently. The better the quality of your existing code, the better conversion tools will do in translating it to another programming language.
  • You lack expertise in both mainframe languages and modern languages.
  • You have a good reason to need to convert your code to a different language. Continuing to maintain it in a “legacy” language just wouldn’t make sense.

On the other hand, automated code conversion is probably not a good idea if:

  • Your app is simple or small, and you could rewrite it easily enough by hand.
  • Your app needs to meet particularly stringent performance or security requirements.

And keep in mind that if you do automatically convert code, expect to vet and tweak it afterward – sometimes substantially – to ensure it’s efficient and secure. Don’t treat mainframe application conversion as a simple, one-and-done affair. Automated tools can save you a lot of time and effort, but that does not at all mean that automated conversion is an effort-free process.

I am a member of the mainframe community. I am excited to join in on the conversation.