Can COBOL flexibility, durability migrate?
March 13, 2014
In our report yesterday on the readiness for CHARON emulation at Cerro Wire, we learned that the keystone application at that 3000 shop began as the DeCarlo, Paternite, & Associates IBS/3000 suite. That software is built upon COBOL. But at Cerro Wire, the app's had lots of updating and customization and expansion. It's one example of how the 3000 COBOL environment keeps on branching out, in the hands of a veteran developer.
That advantage, as any migrating shop has learned, is offset by finding COBOL expertise ready to work on new platforms. Or a COBOL that does as many things as the 3000's did, or does them in the same way.
OpenCOBOL and Micro Focus remain two of the favorite targets for 3000 COBOL migrations. The more robust a developer got with COBOL II on MPE, however, the more challenge they'll find in replicating all of that customization.
As an example, consider the use of COBOL II macros, or the advantage of COBOL preprocessors. The IBS software "used so many macros and copylibs that the standard COBOL compiler couldn't handle them," Terry Simpkins of Measurement Specialities reported awhile back. So the IBS creators wrote a preprocessor for the COBOL compiler on the 3000. Migrating a solution like that one requires careful steps by IT managers. It helps that there's some advocates for migrating COBOL, and at least one good crossover compiler that understands the 3000's COBOL nuances.
Yeo goes on to add that "Most of the people with good COBOL migration toolsets have created COBOL preprocessors to do just this when migrating HP COBOL to a variety of different COBOL compilers. You might just have to cross their palms with some silver, but you'll save yourself a fortune in effort." Transformix is among those vendors. AMXW support sthe conversion of HP COBOL to Micro Focus as well as AcuCOBOL.
Those macros were a staple for 3000 applications built in the 1980s and 90s, and then maintained into the current century, some to this very day. One of the top minds in HP's language labs where COBOL II was born thinks of macros as challenges to migrations, though. Walter Murray has said
I tried to discourage the use of macros in HP COBOL II. They are not standard COBOL, and do not work the same, or don't work at all, on other compilers. But nobody ever expects that they will be porting their COBOL. One can do some very powerful things with macros. I have no argument there.
COBOL II/iX processes macros in a separate pass using what was called MLPP, the Multi-Language PreProcessor. As the name implies, it was envisioned as a preprocessor that could be used with any number of HP language products. But I don't think it was used anywhere except COBOL II, and maybe the Assembler for the PA-RISC platform.
Jeff Kell, whose 3000 shutdown at the University of Tennessee at Chattanooga we've chronicled recently, said macros were a staple for his shop.
In moving to COBOL II we lived on macros. Using predictable data elements for IMAGE items, sets, keys, status words and so forth, we reduced IMAGE calls to simple macros with a minimum of parameters.
We also had a custom preprocessor. We had several large, modular programs with sequential source files containing various subprograms. The preprocessor would track the filename, section, paragraph, last image call, and generate standard error handling that would output a nice "tombstone" identifying the point in the program where the error occurred. It also handled terminal messages, warnings, and errors (you could put the text you wanted displayed into COBOL comments below the "macro" and it filled in code to generate a message catalog and calls to display the text).
It's accepted as common wisdom that COBOL is yesterday's technology, even while it still runs today's mission critical business. How essential is that level of business? The US clearinghouse for all automated transfers between banks is built upon COBOL. But if your outlook for the future is, as one 3000 vet said, a staff pool of "no new blood for COBOL, IMAGE, or VPlus," then moving COBOL becomes a solid first step in a migration. Just ensure there's enough capability on the target COBOL to embrace what that 3000 application -- like the one at Cerro Wire -- has been doing for years.