Converting COBOL to C#

How can businesses move safely and cost-effectively from COBOL to an Object Oriented languages such as C#? This document explores migration through automated code transformation, a mature approach being perfected by the software company Anubex, as an answer to this question.

The document explores the key business drivers for making the step from COBOL to C#, and how Anubex’ CodeTurn makes this transition possible. It will explain the added value Anubex migration offers over other approaches, and demystify the migration process. A detailed white paper with a step-by-step look at the way COBOL can be transformed into working, maintainable C# code is available upon request through the button at the top of this page.

1. Why convert from COBOL to C#?

1.1 Reasons to go to C#

There are many good reasons to make the move to C# from COBOL, but the following are the largest concerns for businesses today:

C# offers answers to all of the above concerns:

Next to that, moving to C# also means:

1http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
2http://www.ecma-international.org/publications/standards/Ecma-334.htm
3https://docs.microsoft.com/en-us/dotnet/articles/core/index
4http://www.mono-project.com/

1.2 Approaches: Replacement, Rewrite or Automated Migration

Once the need to move away from COBOL has been established, the next big question is: how to turn a large, mature COBOL code base into its OO equivalent?

Most organizations take one of three approaches:

Replacement by COTS software is the most cost-effective solution, but only practical if one can actually find 3rd party software that offers the same functionality as the existing COBOL application.

Rewriting on the other hand too often has led to huge costs and ultimately to project failures. According to a research note from Gartner(5) the cost for rewriting is between $6 and $26 per Line of Code (LOC), and accomplished at a rate of 160 LOC per day and per developer. Extrapolated even to a moderate code base of 1M LOC, it is obvious that these will become very expensive, lengthy and risky projects.

Anubex advocates automated migration as the only realistic approach for large, legacy COBOL applications:

All the above, combined with a vast experience in executing migration projects, gives Anubex the confidence to offer projects with fixed duration and fixed price, equivalent functional behavior and equivalent performance.

Like most IT projects, a migration project is a complex undertaking, one that deserves the right amount of expertise and dedication. Anubex has developed project and product methodologies over the past decades to deal successfully with these challenges: we are happy to provide you with more information regarding these.

5Gartner Research Note "Forecasting the Worldwide IT Services Industry: 1999,1"

2. COBOL to C#: Architecting a Conversion

This section focuses on the underlying design principles that any migration from COBOL to C# should take into account, and how Anubex has incorporated these in its flexible toolset.

2.1. Keys to a Succesful Migration

What are the keys to a successful migration project? A primary concern in any migration is how to validate the functional correctness of the migrated programs. In COBOL to C# migrations, this can be hard, especially if the COBOL programs are driving business-critical processes and they are being adapted to evolving user requirements while a migration is running at the same time.

Under these circumstances, migrations should target:

Equivalent program behavior and performance
For programs to be functionally correct, business users have to accept them. For large COBOL applications that are being actively maintained, users and developers have an existing and well-tried process to specify changes, develop, test and bring new releases into production. This familiar process should not be disturbed by migration efforts. An important best practice in migrations is targeting functional and performance equivalence with the production release, and avoiding whenever possible the introduction of functional extensions that don’t exist in the COBOL application. This approach makes it possible to leverage automated testing tools to reduce project costs, improve accuracy and move the project forward faster.

Automated, iterative processes
To manage risk, the generally accepted process in migrations is no different from that of conventional software engineering: using agile, iterative processes that can periodically align the migration project to the latest versions of the COBOL programs undergoing the migration. Consistency and speed are also critical to a parallel iterative process. Using tools to automate the migration imposes rigorous consistency of transformation and brings the end goal within reach of stakeholders.

Developer confidence
There are many differences between COBOL (a structured, compiled, business-oriented language) and C# (an object-oriented, managed, multi-purpose language). COBOL developers that need to maintain the new C# programs will need to be confident in their ability to recognize the business rules and correctly implement and test the changes they make after the migration is completed. Meanwhile, new C# developers also need to feel comfortable with the migrated code to maintain it like any other regular program.

2.2 Key traits of a Professional Software Conversion Tool

The key hallmarks of a professional language translation tool are the way it can strike a balance between three spectra of interest. Anubex’ CodeTurn for COBOL transformation offers a solution to each of these areas:

Customization and Consistency
Anyone who has written software in a team before, knows any program can be written in a variety of ways. A professional software code transformation tool will provide the means to apply customization options that suit the requirements of the customer. These options can be simple things like naming conventions and the formatting of comments, or they can be more sophisticated, like the extent to which the tool will optimize structural patterns in the COBOL code. At the same time, the tool should make it possible to manage such a configuration of customization options for a consistent application in an iterative process. These management facilities should also include configuration of other aspects of the migration like the translation of scripts, screens, or databases.

Maintainability by COBOL and C# Developers
Consistent translation improves the maintainability of the generated C#, but for the C# code to be easy to work with for the original COBOL developers, it also needs to be based around simple design principles. This means the tool should generate code that allows as much as possible a 1:1 relationship between the number of lines of COBOL code and the number of lines in the target language, and reuse (wherever it is syntactically allowed) the names of identifiers appearing in code. This will facilitate the recognition of business entities and rules in the target language by the COBOL developer. At the same time, C# developers with limited exposure to COBOL should be able to pick up the programs and be optimally productive in the shortest possible timeframe. Simple design principles improve the understandability of the converted programs also by these developers. Typical COBOL constructs that are unknown in C# (like DECLARATIVES or PERFORM) are transformed into their closest equivalents in the target languages.

Functional Equivalence with COBOL and Full Support for the Target Platform
The basic requirement of a conversion tool is that the code it produces is 100% functionally equivalent (including side effects encountered at runtime) with the original COBOL code. At the same time, the code that is produced should enable full use of the richness of the target platform. This means some COBOL language syntax will be replaced with calls to platform APIs in.NET. It also means that the code should be fully usable in modern development tools like Visual Studio and support execution in debug mode. Last but not least, the converted programs must easily be integrated with newly written programs and vice versa, hereby ensuring a solid basis for continuous improvement and further modernization.

2.3 Flexible Tools
2.3.1. Rationale

For transformations from one programming language to another, Anubex has built a set of tools collectively called CodeTurn. These tools share one important consideration: each customer is different, and each migration is different. Every organization has its own development and design standards, patterns and frameworks. Some prefer all data access in a separate layer, others choose for embedded data access.

When migrating from COBOL to C#, some organizations prefer to keep the resulting code relatively close to the original COBOL, for reasons of readability and maintainability by the existing developers. Other organizations will choose a more radical approach and prefer code that uses more Object-Oriented design patterns.
In order to be able to accommodate these considerations, standards, and frameworks the Anubex tools can be parameterized and customized for each project.  

To address the stringent requirements listed above, Anubex has chosen a modular approach to building a migration toolset for all of its supported source technologies (COBOL, IDMS, Natural, …).

For language to language transformations, such as from COBOL to OO, the architectural overview of the internals of CodeTurn looks like this:

  • Parsers that support all COBOL dialect syntax, and also embedded languages (e.g. EXEC CICS or EXEC SQL)
  • Resolvers that link together the AST  that is produced by the parsers with control-flow and data-usage information
  • Conversion rules for all COBOL syntax, from single statements to complex patterns of code, as part of the COBOL to OO Converter
  • Code generators for Java, C#, and various COBOL dialects enabling any desired coding style
2.3.2. Intelligent Transformation

To keep up with the design principle of a fully automated migration, transformation rules have been implemented in the COBOL to OO Tranformation module to cover all possible edge cases. From time to time this could lead to relatively complicated OO code. Therefore, the conversion tools also recognize coding patterns (by static code analysis) that indicate where simpler, more elegant code can be generated while still staying 100% functionally equivalent to the COBOL original.

A good example of this is the conversion of the COBOL GO TO statement. In its most general use a GO TO statement can implement a complex state-machine and translating this to C# leads again to a state-machine: the conversion engine has a baseline rule that produces this state-machine code. Oftentimes however, a GO TO is simply used as an early exit point (e.g. GO TO exit-paragraph), or as a way to avoid a certain block of code, or even to emulate a loop. In these circumstances, much more elegant code is generated as can be seen further down this document. In a typical project, more than 95% of all GO TO statements are automatically converted to a more structured equivalent.

Static code analysis limits the optimization of the transformed code that can be done by CodeTurn. Application architects can however help to understand additional restrictions and coding patterns that exist, and based on this understanding, new conversion rules can be implemented. Good examples of where this is likely to help are again the use of GO TO, but also the use of code copybooks and ENTRY statements are typical candidates for such optimization.

2.3.3. Procedural vs. Object-Oriented Paradigm

Another example of the importance of flexible tools lies in the preference of some developers for Procedural-Style code, while others prefer to take maximum advantage of OO-concepts.

Anubex offers both variations, as can be seen in the following short COBOL code snippet:

Notes:

 

More information

Our full CodeTurn COBOL to C# conversion white paper delves even deeper into this matter, with 40 pages of comprehensive content including elaborate examples.

Request your copy of this white paper now by clicking the button below!