Taking Steps Toward COBOL Conversions

Syntax, file equation, COPYLIB differences call for planning

By Steve Hammond

Poor Grace Hopper. One fears the late, great admiral who created COBOL rolls over in her grave every time someone says “COBOL on Unix” or “COBOL on Linux.” Her language was created for big mainframes with lots of blinking lights and dozens of spinning tape drives, not for servers that can fit under a desk, or worse, on a desktop.

But that’s what is happening, and many users of the HP 3000 have found a means to port the old workhorse of a language over to another platform as the end-of-life on the 3000 draws ever closer.

Two people who have gotten into the world of COBOL on another platform are Duane Percox of K-12 app provider QSS and Ken Robertson of migration and services provider AD Technologies. Their experiences have shown that the transition can be done, but there are some ‘bumps in the road’ and planning helps make the transition smoother.

The COBOL products being used are Acucorp’s AcuCOBOL, MicroFocus COBOL, and Fujitsu NetCOBOL. AcuCOBOL will run on both the 3000 and the 9000, so there is an advantage to following the HP migration path, but none of the trails are without effort.

The first difference anyone will notice between what the standard 3000 COBOL/iX user expects and what they will find in the “new” versions are syntactic. AcuCOBOL is syntactically the closest to COBOL/iX, having worked out most of the bugs. Meanwhile, a difference found in NetCOBOL is that the symbol “<>”, used to represent “not equal” is not recognized. It must be replaced with the actual words “not equal” or “not =”.

Other differences on varying versions include that the syntax of “CALL...GIVING” must be replaced with “CALL...RETURNING”. The new COBOLs do not accept variables in octal, so any of those values must be replaced with the hexadecimal representation; i.e., escape, represented as octal 33, must be represented as hex 1B. This is just the tip of the iceberg — there are many other differences, some because of bugs in the COBOL compiler, both on the HP 3000 platform and on the target platforms.

On a different level, the issue of the HP 3000’s file system versus any Unix-type of file system causes significant issues. “You don’t have any file equations,” said Robertson. “You can’t declare a file equation in the job to redirect it to a different file. You have to rethink it.” Percox echoed the discovery. “You just can’t do as much with the JCL.”

Beyond that, there are no message files, no RIO files, no circular files and no KSAM files. “We have just finished a project that used message files on the e3000,” said Robertson. “We had to redesign how we did things.”

Further issues include COPYLIBs — since COPYLIBs are KSAM files, they do not “travel” to a different platform. “We had to turn each section of a COPYLIB into a separate file and use them that way,” added Percox. One thing that both Robertson and Percox noted is that MicroFocus COBOL and NetCOBOL do not allow the use of macros. AcuCOBOL permits you to use these macros, which all allow you to produce in-line code with variable substitutions. Of course, calling any intrinsics, such as FREAD or HPFOPEN, is not possible, again forcing some re engineering.

Although it allows macros, Robertson noted that AcuCOBOL has some performance issues. AcuCOBOL does not create executables, so on a large project, with a large number of subprograms, performance may degrade.

Dealing with databases introduces a new set of issues. AcuCOBOL has an add-on giving it the Oracle access layer. This new database leads to a significant increase in cost, since Oracle requires a fee for every run-time user of the product. If you have hundreds of users, this could call for a sizeable financial commitment. Robertson saw the projected cost of one conversion go over $700,000 when he factored in Oracle fees.

On the other side of the coin (figuratively and literally), for a few thousand dollars Eloquence gives you a database which uses the same database calls as TurboImage, so COBOL changes are not as significant. But Eloquence locking strategies are different, and locking must be addressed in the early stages of any conversion project. Take note that Eloquence has not been tested yet in the field with more than 500 concurrent users.

Percox is in the process of migrating the QSS suite of programs to the Linux platform using PostgreSQL as the database. He has been able to write scripts on the Linux side to modify source code when it is moved there to deal with syntactical problems. He has also been able to use his HP 3000 to “test” some of the changes.

“We do as much on the e3000 as possible to test” some source code changes, he said. Pascal and SPL subroutines are being recoded into C and changes are being made to the TurboIMAGE databases to make them more SQL-like. For example, he has split up combined database fields to make them SQL-like. With help from his user community, he reports significant progress getting his software onto Linux.

Both these developers reflect the caveats of other system conversion professionals — the better the up-front planning and testing, the smoother the conversion. And as MPE and HP’s 3000 move to join CPM and the Apple II, more COBOL users are going to have to follow the path people like Robertson and Percox have built.