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.
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 68||COBOL 74||COBOL 85|
|COBOL 85 Win32||RM/COBOL||MF/COBOL (MicroFocus)|
|IBM COBOL||COBOL II||COBOL II Win32|
|AS400 COBOL||ACUCOBOL - 85||ACUCOBOL - GT|
|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
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.