CodeLiberator

CodeLiberatorTM is the smartest block of our legacy modernization framework for converting complete legacy applications including business logic, UI, and data access layers. This tool uses metadata created by KnowledgeLiberatorTM to transform business logic developed in 3rd and 4th generation programming languages into complete new applications using the Java technology stack. Key features of CodeLiberator:

  • convert business logic from one programming language to another one e.g., COBOL to Java, Natural to Java, PL/I to Java, PL/I to COBOL, etc.
  • convert online transaction processing: convert different legacy user interfaces like 3270 CICS/BMS, IMS-DC, Unix terminals to thin client solutions JSF, HTML/JavaScript (reactive programming) with JSON etc.
  • convert embedded data access in legacy applications to execute the same logic on migrated databases, preserving all data retrieval and manipulation logic on RDBMS, NoSQL, or files.

Language conversion under the hood

Language conversion is easy, one would say. Sure, creating equivalents of data definition, language specific instructions, program flow, etc. Even creating object oriented code with base classes and inheritance is conceptually approachable. The devil is in the details: run the code and create the exact same output for the same inputs most probably can be considered as a success criteria but maintainability and performance should also be treated in parallel. As an example, a COBOL or Natural string must not just simply be converted to a Java string because the innate behavior of strings in the two language realms are different. Of course if we still insist on the same behavior – and normally this is the case – then there will be additional coding in Java needed, which surely would affect maintainability in a negative way and apply WET techniques against DRY. Various flavors and version of a legacy language do have differences in their implementation that we must consider.

We must bear in mind that we usually convert “live” code that are part of the everyday business and actively developed. After conversion, this code must be in a shape that developers can modify, develop, refactor, and do what developers usually do with code.

When converting to Java, the result may come out resembling more like legacy or more like Java. There are many conversion parameters that control how happy a legacy developer would be looking at the Java code as opposed to how happy a Java developer is when looking for common Java constructs and language elements in the new code.

User interfaces

Converting complete legacy applications 

In the modern open world, there are not too many different high level approaches to generating user interfaces. Web interfaces are the predominant species that may come in many different implementations from bare html/javascript (with or without simple frameworks, e.g., jQuery) or higher level application frameworks, e.g., Angular, React and alike.

Our CodeLiberator captures screen definitions and transforms them into set of descriptors. These descriptors then fed into a lightweight “player” in a web browser that creates the look and feel of the original screens. This is so far the “piece of cake” part of the venture.

The challenge is in recreating the original behavior with focus movements, event handling, data handling, server communication, error handling, data validation, etc.

Our solution comes with a screen editor that enables developers to go unison with the converted code once changes must be made.

Data access layer

We add a layer between the converted app and the selected new database engine to provide the exact same functionality. This approach makes it possible that during application conversion the application logic does not have to be changed, functionality and algorithms work as-is. Using this approach our customers do not have to add unnecessary complexity to the first step of the migration, no refactoring required. Move to the open world fast (replatform), and when the mainframe is left behind plan for the next move: refactor, rearchitect.

This added layer makes it possible to abstract the database engine away and enjoy the freedom of picking from either SQL or NoSQL database engines.

Comments are closed