PL/I conversion

PL/I conversion to Java or .NET

CodeLiberator converts Mainframe or open system PL/I applications either to Java or .NET platform including the business logic, data access and the user interface.
When the underlying database is migrated, the data access statements are properly converted depending on the target database which can be relational engines (Oracle, DB2/UDB, MSSQL, etc.) but also NoSQL solutions or simply files. We support different kind of data access types like separated DAO to keep it transparent or standard SQL.
Various type of user interface solutions usually coming with PL/I e.g. CICS/BMS or IMS/DC are also converted to the target that can be JSF or platform independent HTML/JavaScript (reactive programming).
Just like in other language conversions, all PL/I specific language elements (attributes; data types; functions; controlling structures) are fully supported by the solution, among others the ALIGNED, POINTER and GOTO. CodeLiberator is able to apply more patterns during conversion for managing the INCLUDE files and other pre-processors of PL/I to find a reasonable balance between maintainable code and retaining code-reuse concept. The syntax and structure of the code is straightforward and simple to follow both for new developers and PL/I programmers as well as it reflects the naming convention and the structure of the original programs.

What PL/I sources should be used as the right input for conversion?

One of the most interesting challenges of PL/I conversion to Java is raised by pre-processor statements like %INCLUDE, %DECLARE, %ACTIVATE, %IF – %THEN – %ELSE, %DO – %END, etc.
When the PL/I sources contain pre-processor statements (procedures) then obviously the “source” code is different from the one that is finally passed to the PL/I compiler. These pre-processor statements/procedures are executed just before the compile and may alter the source code by adding or removing code parts. So after all, the question is which code should be the input for a language conversion, the one before or after PL/I pre-processing.

Taking both future maintainability of Java and feasibility of automated conversion to Java into consideration, the most optimal way is to use a combination of sources before and after pre-processing. It is not unusual that PL/I based systems and application contain several millions of LoC, the process for deciding between before-after PL/I pre-processing should be also automated.

When sources before PL/I pre-processing should be used as input for PL/I to Java conversion

The concept for pre-processing mainly serves 3 goals: code reuse, improve maintainability, increase performance. The most simple example for this is the %INCLUDE processor enabling highly efficient code reuse. Whenever possible, the separate program and include file concept has to be preserved by any migration solution to Java otherwise overall maintainability of the target application will considerably decrease. If the PL/I conversion solution does not support that feature automatically at all, that poses serious risk to the PL/I migration project!

When sources after PL/I pre-processing should be used as input for PL/I to Java conversion

In cases when the PL/ source file cannot be parsed as a syntactically correct and complete unit then the technically reasonable code conversion of the original source file is not possible and the source file after the PL/I pre-processing needs to be converted.
This approach might be also needed when the conversion of un-processed source files result in unacceptable side effects. Side effects of this case is caused by the fact that the execution of statements originally placed in pre-processing phase is shifted to the application execution time in the target scenario. The effect may be converted code with poor maintainability or poor performance.
LiberatorWorkbench allows human intervention in PL/I to Java conversion rules so when code of low quality or performance is resulted by the default (source files before pre-processing) conversion algorithms, it may be altered by conversion experts to find the right balance.
The PL/I pre-processor allows several language constructs which from a code conversion perspective prevents un-processed source files to be converted to Java reasonably.

Conversion of PL/I specific elements to Java

Converting PL/I code to a functionally equivalent system in Java can be considered successful when the target system provides original identical data and services in any stages of execution. Consequently the right conversion technology must be capable for implementing all PL/I specific construct in some format. The key PL/I specific language elements are covered in various phases and ways by FreeSoft’s LiberatorWorkbench.
Managed at code conversion phase or by specific utilities:

• Default attributes
• Declarations containing LIKE attributes
• A resolution of non-fully qualified names
• Identification of data types for all symbols (variables, literals, functions)
• Dynamically allocated variables
• Variable scoping
• Identification of Array cross sections references
• GOTO label constructs – code slicing, throwing exceptions, etc.
• Creating methods from ON conditions
• Bit precise implementation of PL/I data types
• Dynamic allocation/removal and usage of variables
• Handle array cross sections references
• PL/I I/O (Stream, Record, …) operations, dependencies from OS (e.g. pathname format)
• implicit type conversions
• bit precise implementation of PL/I built-in functions/pseudo variables (SUBSTR, INDEX, UNSPEC, etc.

Customization of PL/I conversion processes

FreeSoft’s code conversion technology was designed and implemented to allow customization of rules in all phases (parsing; modelling; code generation) of the conversion process according to specific client requests for target architecture and code syntax.
In the initial phases the rules define which state of source files (before or after PL/I pre-processing) will be used as the input for conversion. LiberatorWorkbench engine also accepts lists to define group of sources to be taken after pre-processing.
The modelling phase also allows custom rules to be executed on the intermediate code models by refactoring.
Finally for code generation we also use pre-defined custom rules and patterns e.g. naming conventions, syntax for different statements, pattern for external calls (service calls) etc.

Don’t hesitate to request a sample conversion by sending us a couple of PL/I programs or sign-up for a demonstration so we can drive you through the process of converting PL/I to Java.