This article explores automated code transformation as a fit-for-purpose strategy for migrating existing z/Architecture Assembler (HLASM) code bases (originating on source operating systems like z/OS, z/VSE, z/VM, z/TPF, …).

Some of the topics discussed in this page include:

  • Some of the key business drivers for transforming z/Architecture Assembler to C#.
  • How Anubex’ CodeTurn makes this transformation possible, and the added value Anubex migration offers over other approaches.
  • A demystification of the migration process with a step-by-step look at the way z/Architecture Assembler can be transformed into working, maintainable C# code.

1. Why transform z/Architecture Assembler to C#?

1.1. Reasons to choose C#

There are many good reasons to make the move to C# from z/Architecture Assembler, but the following are among the most often cited concerns for businesses:

  • High (and continuously increasing) mainframe maintenance and runtime fees.
  • Very strong vendor and platform lock-in.
  • A shortage of skilled mainframe Assembler developers (even more pronounced than for other more approachable mainframe technologies like COBOL, Natural, ADABAS).
  • A general lack of interest in mainframe technologies among younger developers.
  • Lack of (easy) application extensibility and interoperability .
  • Overall lack of agility (not being able to implement new business features in a timely fashion).

C# and the Microsoft .NET platform offer answers to all of the above concerns:

  • Support fees are negligible (or even non-existing, depending on the choices made).
  • C# is one of the most widely-used programming languages today[1] , and it is the language of choice for instruction in the IT programs of many schools. Documentation of the language, software libraries, and development tools are also available free of charge.
  • C# and .NET are actively being developed by Microsoft and the product and its documentation are publicly available on the Internet (earlier versions were also official ISO/IEC and ECMA[2] standards).
  • Interoperability with all Microsoft platforms and technologies is a given and portability to other platforms is being actively developed by Microsoft in the form of .NET Core[3]; with the Mono[4] project also providing cross-platform capabilities.

Next to that, moving to C#/.NET also means:

  • Enabling the use of a state-of-the-art IDE in the form of Visual Studio, with extensive debugging, refactoring, profiling and (unit)testing support.
  • Enabling the use of thousands of third-party libraries, covering almost all imaginable computing needs:  UI‑development, database interaction, web services, parsing, XML processing ,…
  • Enabling the use of modern application architectures (multi-tier, SOA or micro-service based) and deployment techniques (cloud, docker, …).

[1]http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[2]http://www.ecma-international.org/publications/standards/Ecma-334.htm

[3]https://docs.microsoft.com/en-us/dotnet/articles/core/index

[4]http://www.mono-project.com/

1.2. Approaches: Replacement, Rewrite or Automated Migration

Once the need to move away from z/Architecture Assembler has been established, the next big question is: how to turn a large, mature z/Architecture Assembler code base into its C# equivalent?

Most organizations take one of the following approaches:

  • Replace by third party COTS (Commercial Off-The-Shelf) software.
  • Rewrite.
  • Transform 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 application.

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. It is safe to say that rewriting assembler code would end up being performed at a cost that is at the upper end of this range. Extrapolated for even moderately sized code bases, 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 z/Architecture Assembler applications:

  • It offers consistency: since all code is transformed 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 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: existing developers and IT department can keep working on their daily tasks, including the ongoing maintenance of the z/Architecture assembler code.

All the above, combined with a vast experience in executing migration projects, gives Anubex the confidence to offer projects with fixed duration and fixed 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 over the past decades to deal successfully with these challenges: we are happy to provide you with more information regarding these.


[1] Gartner Research Note "Forecasting the Worldwide IT Services Industry: 1999,1"

2. z/Architecture Assembler to C#: Architecting a Transformation

This section focuses on the underlying design principles that any migration from z/Architecture Assembler to C# should take into account, and how Anubex has incorporated these in CodeTurn.

2.1. Keys to a Successful Migration

What are the keys to a successful migration project? A primary concern in any migration is how to validate the functional correctness of the migrated programs. In z/Architecture Assembler to C# migrations, this can be hard, especially if the z/Architecture Assembler 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 z/Architecture Assembler 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 the production release, and avoid whenever possible the introduction of functional extensions that don’t exist in the z/Architecture Assembler application. 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 z/Architecture Assembler programs undergoing the migration. 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 z/Architecture Assembler (a low level, platform specific language) and C# (an object-oriented, managed, multi-purpose, hardware agnostic language). z/Architecture Assembler developers that need to maintain the new C# 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. Meanwhile, new C# developers also need to feel comfortable with the migrated code to maintain it like any other regular C# program.

2.2. Key Traits of a Professional Software Conversion Tool

The key hallmarks of a professional language translation tool are the way it can strike a balance between three spectra of interest. Anubex’ z/Architecture Assembler-to-C# conversion toolset offers 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 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 extent to which the tool will optimize structural patterns in the z/Architecture Assembler 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 z/Architecture Assembler and C# Developers

Consistent translation improves the maintainability of the generated C#, but for the C# code to be easy to work with for the original z/Architecture Assembler developers, it also needs to be based around simple design principles. This means the tool should generate code that allows as much as possible a 1:1 relationship between the number of lines of z/Architecture Assembler code and the number of lines of C#, and reuse (wherever it is syntactically allowed) the names of identifiers appearing in code. This will facilitate the recognition of business entities and rules in C# by the z/Architecture Assembler developer. At the same time, C# developers with exposure to z/Architecture Assembler 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 C# developers. Typical z/Architecture Assembler constructs that are unknown in C# are transformed into their closest C#-style equivalents.

Functional Equivalence with z/Architecture Assembler and Full Support for the Target Platform

The basic requirement of a transformation tool is that the code it produces is 100% functionally equivalent (including side effects encountered at runtime) with the original z/Architecture Assembler code. At the same time, the code that is produced should enable full use of the richness of the target .NET platform. This means some z/Architecture Assembler language syntax will be replaced with calls to .NET APIs. It also means that the code should be fully usable in Visual Studio and support execution in debug mode. Last but not least, the converted programs must easily be integrated with newly written C# (and to a wider extend: .NET) programs and vice versa, hereby ensuring a solid basis for continuous improvement and further modernization.

2.3. Flexible Migration Tools

For transformations from one programming language to another, Anubex has built a set of tools collectively called CodeTurn. These tools share one important consideration: each customer is different, and each migration is different. Every organization 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.

To address the stringent requirements listed above, Anubex has chosen a modular approach to building a migration toolset for all of its supported source technologies (z/Architecture Assembler, COBOL, IDMS, Natural, …).

For language to language transformations, such as z/Architecture Assembler to C#, the architectural overview of the internals of CodeTurn looks like this:

  • Parsers that understand the z/Architecture Assembler listings as produced on the mainframe platform
  • Resolvers that link the AST[1] produced by the parsers with control-flow and data-usage information
  • Conversion rules for all z/Architecture Assembler syntax, from single statements to complex patterns of code, as part of the z/Architecture Assembler to C# transformation tool.
  • Code generators for C enabling any desired coding style.

[1] AST stands for Abstract Syntax Tree, a hierarchical representation of a source file’s actual contents

More information

To learn more, request your copy of the full 30-page z/Architecture Assembler to C# transformation whitepaper, including elaborate examples,

Want to know more?

Anubex has the right solution for you! Don’t hesitate to contact us with your inquiries.

CONTACT US