Frequently Asked Questions


Have you worked on very large assembly-language conversion projects?

MicroAPL has over thirty years experience in assembly-language translation, during which time we have successfully worked on some very large projects. For mainframe projects, we have translated code sizes ranging from a few thousand to over 3 million lines of assembler code.

Why not use AI directly on the assembly language code to convert it to Java/C#?

AI systems need to be trained on large amounts of sample data before they can be effective. There simply isn't enough training data available to AI systems for them to do a good job of understanding and refactoring mainframe assembler code, especially given the complexity of the HLASM assembler. On the other hand, there is a huge amount of sample C, C# and Java code available to the AI models, making conversion between C and good-quality Java or C# practicable - provided the C source is itself of good quality.

In addition, in a real code migration project there will be design and refactoring decisions which require manual intervention. MicroAPL's Relogix translator has been tuned over many years to provide the hooks to allow the translation to be guided successfully over large assembler code bases.

Why not get Relogix to output Java or C# rather than C?

The architecture of the C language is much closer to assembler than modern languages which do not implement pointers. That makes it much easier to produce a translation which is readable and maintainable but still can be related back to the original. It also means that it is possible to test the translated code directly against the original assembler, making debugging much easier (for example, to find errors caused by endian dependencies which haven't been correctly handled).

Do we have to translate the whole codebase in one go, or can we translate and test incrementally?

If possible, we recommend an incremental approach, where modules (or a group of closely-related modules) are translated to C and preferably tested in the C version, before being converted to Java or C#. Depending on the technical details, it may be possible to test the C code on the mainframe, possibly replacing assembler modules with their C equivalents (we can automatically generate any 'glue' code needed to interface the old assembler modules to the translated C modules).

Some of our modules are rarely run and we don't really need to develop them further. Can we leave them in C and run them in a hybrid Java/C or C#/C environment?

Yes, in some cases this will be a good approach. Especially if they are standalone programs (for example, code to generate a report weekly), you might decide to leave them in C for now. You can always translate them to Java/C# later.

Do you recommend any particular AI system for translating the C source which Relogix generates?

This is a fast-changing field, and our clients may have experience with various different AI systems, so we don't recommend any particular AI system. In many cases it will be appropriate to use one of the companies which specialise in code migration of high-level language mainframe software.

Can we license Relogix to run on our own in-house systems?

Yes, subject to commercial terms we can install Relogix on your Linux servers or PC workstations. However, to get the best quality translation we would need to work with you on the migration process.

Can you customize Relogix to handle migration problems specific to our assembler code, such as refactoring database interfaces?

In most cases, it will be possible to handle specific idioms or refactoring of interface software without customizing Relogix. For example, an assembler macro which fills in a control block and then calls a system support modules can be replaced with a simpler and cleaner alternative. For more complex refactoring, on large projects we often provide customised extensions to Relogix to improve the code quality for customer-specific idioms in the assembler.

Our assembler code uses cryptic names for routines and data items, such as "FNK#AAB" or "DBLTDA". How can we change these to more meaningful names in the translated code?

Relogix makes it very easy to map assembler symbols to meaningful names in the translation. AI systems are very good at automating the production of the Relogix 'Hints' needed to specify such mappings over a large codebase, by reading the comments in the first cut of the translated C code.

What is involved in tuning the Relogix translation?

Documentation on using Relogix and tuning the translation is available for download here.

Do you publish sample translations?

Yes. You can see samples of Relogix-generated C source here, and of the results of translating to Java here.