Updating COBOL programs: Pitfalls to avoid when going from COBOL to C

To keep operational expenses low, keep these modernization considerations in mind when dealing with COBOL programs.

Operational and support costs for maintaining a legacy Common Business Oriented Language (COBOL) system can be high. A company's ability to enhance and scale COBOL programs may be hampered by prohibitive costs of meeting additional operational requirements.

To keep the operational costs at more manageable levels, the company should consider these modernization options:

  • Manually rewriting the legacy code from COBOL to C/C++
  • Rehosting the legacy system on a new platform
  • Automatic conversion of the legacy system into C/C++

Modernizing COBOL programs by rewriting legacy code is labor-intensive and human-error prone. The second option may require minor changes to the legacy system to be rehosted. The ability of a rehosted legacy system to meet growing operational requirements is not guaranteed. The third option may require outsourcing to a third party that can deliver the converted product at the least cost with the lowest technical risks and in the shortest time possible.

C/C++ is the most commonly used target programming language. C++ uses object-oriented programming concepts like classes, objects and polymorphism.

Less commonly used is the C#, a .Net language. In some ways, it is similar to Java. C# runs slower than C or C++ because it runs on a virtual machine rather than a native one. The speed difference may go unnoticed on a faster computer.

COBOL dialect pitfalls

Do the following to sidestep the pitfalls when converting COBOL programs:

  • Avoid COBOL statements specific to a dialect.
  • Avoid reference formats not commonly used.
  • Determine the maximum number of columns for a code line.

In one dialect, COBOL code begins in the eighth column (after six columns of sequence number and one indicator area). In another dialect, the code begins in the second column (after the first column of indicator area).

In one dialect, COBOL provides a single character for a compiler directive in the reference format. For another dialect, this notation is not available in the reference format. The standard list includes a single character for each information type: comments, debugging lines and continuation lines.

In one dialect, the number of columns where code lines are accepted is 132, while in another dialect, it's 72.

In one dialect, there isn't' a distinction between Area A and Area B for COBOL code. In another dialect, distinction is made between Area A and Area B. Items that must begin in Area A include Division headers, Paragraph headers, and DECLARATIVES. Items that must begin in Area B include entries, sentences and continuation lines.

Tool selection pitfalls

To avoid the pitfalls of selecting the wrong conversion tool, do the following:

  • Make a checklist of what statements are specific to a dialect.
  • Test with small programs, each with different parameters
  • Check conversion performance for each test.

Lowest cost doesn't mean lowest technical and implementation risks. You may find the risks may be higher for the tool with the lowest cost in your ROI analysis.

Don't expect 100% conversion without issues. Output code still needs to be debugged with the target compiler to resolve target compilation issues.

Consider conversion tools from Micro-Processor Services Inc. (MPS), TSRI and Language Portability Solutions Inc. MPS offers three translator converters: COBOL to C (COB2C), COBOL to C++ (COB2CPP) and COBOL to C# (COB2CS), each of which accepts many COBOL dialects.

COBOL dialects supported include:

COBOL 85 Win32 RM/COBOL MF/COBOL (MicroFocus)
Realia COBOL (Computer Associates)    

The Software Revolution Inc. (SRI) provides a suite of tools for automatic conversion from MicroFocus COBOL and ProCOBOL into C/C++. Language Portability Solutions offers service to convert from COBOL to C#.

Target compilation pitfalls

More on COBOL programs

How to implement a browser interface in COBOL

COBOL coding techniques for peak performance

How to detect a dropped session from a COBOL program

One main pitfall is memory overflow in a target C/C++ program language during the compilation process. When too much memory is used on the call stack, stack overflow can occur. More memory is allocated on the stack than it will fit. The stack size depends on the amount of available memory.

Stack overflows are made worse by reducing the effective stack size of a given C/C++ program. When you run the program in multithreading mode, the programs with threads have less stack space per thread than a program with no threading support or that is assigned to a single thread.

About the author: 
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, information assurance, financial, RFID technologies and project management. 

Follow us on Twitter @SearchSOA and like us on Facebook.

Dig Deeper on Application management tools and practices

Software Quality
Cloud Computing