The Translation Trap

This article raises the issue of translation errors. Most COBOL users can not afford to either introduce subtle (or not) translation errors into their production systems or spend lots of time testing for logic accuracy. If they are going to move off their proprietary COBOL platforms, there is already enough to worry about.

This is a fair concern. The COBOL to Java translation technology has been greatly improved and Heirloom Computing has successfully helped customers get to Open Systems Java. Clearly those shops were comfortable with the results but they WANTED to go to Java.

Many don’t want to translate. Perhaps they want to explore translation someday, maybe. But they just want to stop spending exorbitatnt amounts for developer seats, compiler licenses, and runtime licenses or mandatory support fees. They may not even want to change their current platform (z/OS, Window, MacOS, Linux).

We think translation from COBOL to COBOL is a thing. We think Open Source Software (OSS) compilers (GnuCOBOL or GCC COBOL) are excellent translators of COBOL software programs to modern, POSIX ABI compliant, machine-language programs. GnuCOBOL is the older of the two projects and has excellent coverage of many “dialects” of COBOL (IBM, Microfocus, RM COBOL, AcuCOBOL, &c.). GCC COBOL is a more modern COBOL compiler but still young. It is built as an integral part of the Gnu Compiler Collection, a “front-end”. GCC COBOL and GnuCOBOL have both passed the NIST CVVS Standards Verification suite for COBOL 1985. In addition, both run additional tests as a matter of course.

COBOL to COBOL “translation” (recompilation) with either OSS compiler addresses the article’s concern about translation. He raises the dreaded skills gap. It seems mandatory. I presented COBOL for Finance and Admin at the Free and Open Source Software Conservancy convention recently. Many OSS household names were in the room and when it came to my claim that an experienced programmer could learn it quickly, there was agreement in the room after a look at some code.

COBOL is easy for an English-reader/speaker to understand. Its structure and language is clear and easy to understand. Like all code, complex programs in COBOL are as hard to read as complex programs in any language. So asking a team member to go fix a COBOL program may require a few days of study, with COBOL you aren’t learning the language and a seemingly endless panoply of library modules. Everything you need is in the Language Manual. And you can generally use the manual for compiler A to work on code for compiler B. COBOL is highly standardized and the core language is the same everywhere (-ish).

So, PLEASE, take a look at more thoughts along this line at our website especially under the Modernization tab.

We are waiting to help anyone with COBOL language problems from any compiler and to join in Proof of Concept or merely blue-sky brainstorming conversations about these two compilers, GCC COBOL (gcobol)and GnuCOBOL (cobc).