Every migration project presents its own challenges, but this very simplified diagram shows the overall roadmap for refactoring a mainframe assembler codebase into natural, maintainable Java or C#. (Hover over areas of the image for more information.)
Initially we will carry out an initial outline assessment of the project, including examining the assembler source code, discussions with the client, and running code through our Relogix translator to see what issues emerge and to assess the scope of the translation project. As part of this initial phase, we will usually carry out a proof-of-concept translation of some representative modules in the assembler codebase, so that you can see how well the code translates and gain familiarity with how the translation process works.
We will usually do this free of charge or for a small fee, depending on how much code we have to look at and the degree of detail required.
Issues which would need to be addressed in the 'Detailed assessment and new system design' stage include:
- Replacement of mainframe data access system (often written in-house many years ago) by a standard relational or other industry-standard database
- How data will be migrated, and how issues such as data formats and character mappings will be addressed
- Testing strategy, possibly including parallel running of the mainframe assembler code and translated code
- Replacement of an old-style UI components with modern browser-based alternatives
- Replacement of any IBM or other proprietary system software with appropriate modern alternatives
- Performance constraints and capacity planning
- Any issues relating to multi-threading or multi-tasking
- Security issues
In the main assembler translation phase, RelogixTM is used to translate the assembler code to C source, expanding macros and resolving the complex syntax of IBM's HLASM assembler. This is an iterative process, during which MicroAPL engineers in collaboration with your staff will tune the translation to get the best possible code quality and portability. Improvements to the code quality (such as better-defined data structures and types) then feed back into the Relogix translation and propagate through other parts of the project, in turn producing even better code quality.
For large projects, this phase may sometimes include MicroAPL carrying out custom modifications to Relogix to handle specific issues and idioms of the source code base, both to improve code quality still further and to enable more aggressive refactoring of any mainframe-specific dependencies in the code.
Relogix will automatically create C header files corresponding to the data structures it discovers in the assembler source code, and provide data types for the structure elements. These structures may correspond to DSECTs in the original, in which case there will be be assembler field names and probably comments attached to the fields, or they may relate to numeric offsets from register pointers, in which case Relogix will choose default names. In either case you can optionally provide your own, cleaned-up version of the structures, with more meaningful names and more specific types, and feed these back into the translation to improve code which references these structures.
Examples of other techniques used to improve the code quality in this iterative process include:
- Providing 'hints' to replace the name and/or type of variables generated by Relogix to correspond to register contents
- Renaming the C functions corresponding to assembler subroutines, and optionally providing your own function prototypes
- Providing replacement macros to simplify the translation of module calls where a control block is used to pass parameters
- Dealing with endian- or EBCDIC-dependencies which Relogix has not been able to resolve automatically
A key parameter for success is to be able to test translated code and validate it against the mainframe results. Although it is possible to delay testing until the final Java or C# version of the codebase is developed, it is generally good practice to test the intermediate C code to be sure that you have a sound platform for refactoring. Depending on the technical characteristics of the codebase, options may include:
- Specially-written unit tests
- Hybrid execution on the mainframe, where assembler modules are progressively replaced with their C equivalents (MicroAPL can automatically generate any 'glue' code required for this)
- Parallel running on the mainframe and a Linux 64-bit server
- Parallel debugging to track down any difficult issues
- Automated scripts for regression testing as the translation is improved and refactored.
Once you have a good-quality C translation from which to proceed, there are several options for conversion to the final target of Java or C#. These include:
- Gen-AI systems such as Claude can produce very good quality results, although these need to be checked and tested carefully as they can make mistakes.
- A number of mainframe modernization vendors have sophisticated code migration tools which can take the good-quality code generated by Relogix and convert it to Java or C#. Compared with the Gen-AI approach, this may be more reliable for very large codebases, but the generated code may not be as natural.
- In some cases manual rewriting of at least part of the codebase may be an option. Once the business logic of the original assembler source has been unlocked by Relogix, the converted code can be analysed by an AI system to provide a specification for rewriting, referencing back to the C code for any details. In one of our projects, the client realized on seeing the translated code that many of the modules could be expressed very concisely as SQL queries or views, making it very easy to rework them using stored procedures and a Java wrapper.
Whatever approach is taken, MicroAPL will partner with you and your other suppliers to ensure the success of the project as a whole.
The final testing and deployment phase is much like that of any software development project hosted in the cloud or on a Linux server. There are, however, some special issues which need to be planned for, such as migrating historical data from the mainframe.