How can businesses move safely and cost-effectively from Natural to 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 Natural to C#, and how Anubex tools make this transition possible. It will explain the added value Anubex migration offers over other approaches, and demystify the migration process with a step-by-step look at the way Natural can be transformed into working, maintainable C# code.

A detailed and extensive white paper with a step-by-step look at the way Natural can be transformed into working, maintainable C# code is available upon request through the button at the top of this page.

1. Why migrate from Natural to C#?

1.1 Reasons to go to C#

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

  • High (and continuously increasing) maintenance and runtime fees for the existing Natural products;
  • Shrinking availability of Natural developers and lack of interest in Natural from young developers; and
  • Lack of an easy transition path from the mainframe version of Natural to its Linux, Unix, and Windows platform versions.

C# offers answers to all of the above concerns:

  • Maintenance and support fees are negligible when compared to Natural (or even nonexistent depending on the choices made);
  • Even though there is no one universally accepted barometer to measure the popularity of the various programming languages, there is no denying that C# is considered to be one of the most widely-used programming languages today [1]. In addition, the design of C# aims for programmer portability, for the vast range of developers familiar with C, C++, and Java;
  • Even though C# has been developed by Microsoft, the product and its documentation are publicly available on the Internet (the first versions were even ISO/IEC and ECMA standards). For example the language specification is available here:  https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/index

Next to that, moving to C# also means:

  • Enabling the use of a state-of-the-art IDE, with extensive debugging, refactoring, profiling and (unit)testing support.
  • Enabling the use of thousands of (third-party) libraries, covering almost all imaginable computing needs: database interaction, mail/ftp/http/… communication, parsing, xml processing, …
  • Enabling the use of modern application architectures including the use of an application server, web front‑ends, SOA, cloud-deployment, …

[1]https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Languagehttp://trendyskills.com/

1.2 Approaches: Replacement, Rewrite or Automated Migration

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

Most organizations take one of three approaches:

  • Replace by third party COTS (Commercial Off-The-Shelf) software;
  • Rewrite; or
  • Migrate automatically.

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 Natural application (and provides a migration path for the existing data).

Rewriting on the other hand too often has led to huge costs and ultimately to project failures. According to a research note from Gartner [1] 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.  Even extrapolated to a code base of only 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 applications:

  • It offers consistency: since all source code is translated by software, there can be no differences in quality and all existing functionality is kept as-is;
  • It offers speed and continuous improvement possibilities: a complete code base can be converted in a couple of hours, meaning that this process can be repeated as often as needed or wanted;
  • It offers a very large degree of testability: when keeping the converted application’s functionality and user interface unchanged, the original application’s behavior can effectively be used as a regression test (and running this regression test, too, can be automated);
  • It offers minimal interruption: because of the speed of the conversion, any “code freeze” period before taking the migrated application into production can be kept to a minimum. The existing team can keep working on its daily tasks, including the ongoing maintenance of the Natural code, during most of the migration project; and
  • It gives Anubex the confidence to offer projects with fixed duration and 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, and we are happy to provide you with more information regarding these.


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

2. Natural to C#: Architecting a Conversion

This section focuses on the underlying design principles that any conversion from Natural to C# should take into account, and how Anubex has incorporated these in its set of flexible tools.

2.1 Keys to a Successful Conversion

What are the keys to a successful migration project? A primary concern in any migration is how to validate the functional correctness of the new programs. In Natural to C# conversions, this can be hard, especially if the Natural 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 Natural 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 a production release, and avoid whenever possible the introduction of functional changes that don’t follow the standard development process. 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 Natural programs undergoing the conversion. 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 Natural (a procedural, business-oriented language with a very rich runtime and non-procedural statements) and C# (an object-oriented, managed, multi-purpose language). Natural 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.

2.2 Key Traits of a Professional Software Conversion Tool

The key hallmarks of a professional language translation tool are the way it strikes a balance between three spectra of interest. Anubex’ Natural-to-C# conversion tools offer 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 conversion tool will provide the means to apply a configuration of 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 efforts the conversion tool will spend to detect and optimize structural or object-oriented patterns that are inherent to the Natural 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 Natural 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 Natural developers, it also needs to be based around simple design principles. This means the migration should generate code that provides (as much as possible) a 1:1 relationship between the number of lines of Natural code and the number of lines of C#, and keeps identifiers (variable names, program names, …) as close as possible to the original ones. This will facilitate the recognition of business entities and rules in C# by the Natural developer. At the same time, C# developers with limited exposure to Natural 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 C# developers. Typical Natural constructs that are unknown in C# (like REDEFINES, or ESCAPE handling, or BREAK handling) are transformed into their closest C#-style equivalents.

Functional Equivalence with Natural and Full Support for the Target Platform

The basic requirement of a conversion tool is that the programs it produces are 100% functionally equivalent (including side effects encountered at runtime) with the original Natural programs. At the same time, the code that is produced should enable full use of the richness of the target platform. This means some Natural language syntax will be replaced with calls to .NET APIs. It also means that the code should be fully usable in Visual Studio and support execution in debug mode. And also, the converted programs should easily be integrated with newly written .NET programs and vice versa.

2.3 Flexible Migration Tools
2.3.1 Rationale

For conversions from one programming language to another, Anubex has built a set of tools, collectively called the Language Convertor, with one important consideration in mind: each customer is different, and each migration is different. Every organization for example 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 converting Natural to C#, some organizations will prefer to keep the resulting C# relatively close to the original Natural, for reasons of readability and maintainability by the existing developers. Other organizations will choose a more radical approach and prefer C# that uses more Object-Oriented design patterns.

In order to be able to accommodate these considerations, standards, and frameworks the Anubex tools are parameterized and customized for each project. 

To address the stringent requirements listed in the above two sections, Anubex have selected a modular approach to building migration tools for all of its supported source platforms (Natural, IDMS, COBOL…).

For language to language conversion tools, such as Natural to C#, the architectural overview of the internals of these tools looks like this:

  • A parser that supports the complete Natural syntax;
  • A resolver that links together the AST[1] that is produced by the parser with control-flow and data-usage information;
  • Conversion rules for all Natural syntax, from single statements to complex patterns of code, implemented in function of the target language; and
  • Code generators for Java, C#, and various COBOL dialects, enabling any desired coding style.

[1] AST stands for Abstract Syntax Tree, a hierarchical representation of a source file’s actual contents

2.3.2 Intelligent Conversion

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

Examples of such optimization can be found in the example code of the migration of the Natural loop statements to C#, and in the handling of the DECIDE statements.

2.3.3 Procedural vs. Object-Oriented Paradigm

Another example of the importance of flexible migration tools lies in the preference of some developers for Procedural-style code, while others prefer to take maximum advantage of Object-Oriented concepts which results in OO-style code.

Anubex offers both these variations, as can be seen in the following short Natural code snippet, and the corresponding Procedural‑style and OO-style C# counterparts:

Notes:

3. Natural to C#: A high-level Tour

3.1 Hello World

All Natural program objects get mapped to a C# class that extends a corresponding base class (Program, Subprogram, Map, …); and the top-level program code is located in the Run method.

A NaturalObject attribute is used to mark classes representing migrated program objects, in order to support dynamic steplib-based lookup at runtime (and to avoid any forced correlation between the namespace/class name and the original library/object name).

Let’s start with a simple example, a main program called HELLO, that prints “HELLO WORLD”.

By default, this is mapped as follows:

Notes:

  • A Natural application uses one top-level “driver” class/executable. This driver sets up the Natural environment and executes a main command loop in a new session. This includes log on processing (interactively or in batch mode, based on whether or not Natural Security is in use and how it is configured).
     
  • The actual formatting of the C# source files (e.g. where to put curly braces, how many spaces to use for indentation, using spaces or tabs, …) can be customized.
    For brevity, the code samples shown use a style that is more compact than the default (for example, they have “{“ at the end of lines rather than on their own line).
     
  • The namespace names use a configurable prefix (typically the customer’s company name, here “Customer”), optionally followed by the Natural library name (here, “Library”), with as final component the category and type of the original Natural object (“Code.Programs”, “Code.Maps”, “Data.Database” (DDMs), “Data.Parameter” (PDA), …).
  • Similarly, the mapping of Natural object names is configurable in the tool. By default, it targets “upper camel case”, with '-' interpreted as word delimiter. So a Natural program called “ABC-DEF” will by default result in a class called “AbcDef”. Alternative naming such as “ABC_DEF”, “abcDef”, or “library_abc_def” is equally valid.
3.2 Challenges

When converting Natural, with both its procedural syntax and rich runtime, to a modern OO language such as C#, there are a lot of architectural and behavioral mismatches that need to be overcome:

  • While Natural data items have an associated type (Alphanumeric, Logical, Date, …), they can also be redefined and treated as a completely difference data type. This makes it possible to store “illegal” values (for example, the value “HELLO” could be stored in an alphanumeric redefinition of a numeric field, resulting in an invalid [1] number).
    C# on the other hand is a strongly typed language, which makes it impossible to assign a number to a String variable or vice versa.
  • Natural programs typically use copycodes as a means to re-using code in multiple programs. C# on the other hand does not have the concept of an “include file”.
     
  • Natural control-flow instructions, such as REINPUT and RETRY, simply don’t have a counterpart in C#.
     
  • Natural control-flow instructions such as ESCAPE map rather nicely to exception handling, but the use of exceptions in .NET incurs a runtime overhead when the first exception is encountered during program execution.
     
  • Natural is known for its high-precision arithmetic (29 digits, of which at most 7 can be decimal), which many financial applications rely upon and while C# has a “decimal” data type, its range is not sufficient[2]. The standard .NET library also doesn’t offer a “BigDecimal” type as an easy workaround.
     
  • Natural programs can import database fields using only their name, with types taken from the corresponding DDM module. This means that a data dictionary change, such as extending a text field from 20 to 30 characters, does force a recompilation but no actual code change.

[1] Technically “HELLO” is a valid value for a Natural numeric field (format length “(N5)”); on EBCDIC systems, “HELLO” corresponds to hexadecimal value X'C8C5D3D3D6', and Natural would interpret this as a valid numeric value (-85336).

[2] It can only store 28 digits reliably; 29 digits can only be relied upon if the first two digits are no larger than 79

3.3 Additional examples

Our extended 25-page Natural to C# conversion whitepaper delves deeper into the main challenges of Natural to C# conversion, with examples of C# equivalents of converted Natural code, with the tools configured to their current defaults which produce OO‑style C# code, with many other mappings and configurations possible. Next to the short code snippets like the one above, a more comprehensive program sample is also provided.

Further examples include Natural loop statements, data items, the different types of basic control flow, and REINPUT and RETRY statements.

You can request the full whitepaper at migrations@anubex.com or by clicking the button below.