How can businesses move safely and cost-effectively from Natural to Java? 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 Java, 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 Java code.

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

1. Why migrate from Natural to Java?

1.1 Reasons to go to Java

There are many good reasons to make the move from Natural to Java, 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.

Java offers answers to all the above concerns:

  • Maintenance 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 Java is considered to be one of the most widely-used programming languages today [1]. In addition, the design of Java aims for programmer portability, for the vast range of developers familiar with C, C++, and C#;
  • Although the catch-phrase “write once, run anywhere” may be somewhat disputable, Java certainly is extremely portable.

Next to that, moving to Java 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.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 Java 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 Java: Architecting a Transformation Process

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

2.1 Keys to a Successful Transformation

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 Java transformations, 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 transformation. 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 Java (an object-oriented, managed, multi-purpose language). Natural developers that need to maintain the new Java 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-Java 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 Java Developers

Consistent translation improves the maintainability of the generated Java, but for the Java 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 Java, 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 Java by the Natural developer. At the same time, Java 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 Java developers. Typical Natural constructs that are unknown in Java (like REDEFINES, or ESCAPE handling, or BREAK handling) are transformed into their closest Java-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 Java APIs. It also means that the code should be fully usable in Eclipse and support execution in debug mode. And also, the converted programs should easily be integrated with newly written Java programs (or other JVM languages) and vice versa.

2.3 Flexible Migration Tools
2.3.1 Rationale

For transformations 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 Java, some organizations will prefer to keep the resulting Java 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 Java 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 Java, 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. 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 Java counterparts:


3. Natural to Java: A high-level Tour

3.1 Hello World

All Natural program objects get mapped to a Java 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:


3.2 Challenges

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

[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).

3.3 Additional examples

Our extended 25-page Natural to C# transformation whitepaper delves deeper into the main challenges of this process, with examples of C# equivalents of transformed 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 or by clicking the button below.