ASNA Synon Escape®: Persist your legacy Synon application to .NET

Running a business today with a 25-year-old green-screen application is a perilous adventure. This ASNA white paper discusses how you can escape your critical dependence on your legacy Synon application and ensure business persistence by migrating it to C# and SQL Server on the .NET platform—with optional deployment to the Azure cloud.

The 80s were the dawn of the enterprise application. Back then, many were still using pencil and paper to manage their business. The advent of the AS/400 brought forth a new commodity computer and many businesses realized, that with the right software, the AS/400 could elevate them out of the tar pit of manual record keeping.

During the AS/400 announcement in 1988 IBM proudly proclaimed there were more than 1000 software packages available for its new computer. However, the uniqueness of many businesses (or at least perceived uniqueness) meant that canned packages couldn’t fulfill many specific software needs. If you were in the business of distilling scotch whiskey, or building aircraft parts, or collecting property taxes in Alabama, or fulfilling any of the hundreds of other specialized niches, canned packages didn’t solve your challenge. You needed custom AS/400 software.

This demand for specialized AS/400 solutions quickly created many new jobs. Businesses quickly acquired RPG programming teams and turned them loose to create tailored, custom software. However, it didn’t take long for business managers to realize that writing complex business software is hard work and takes a long time. For large businesses with complex processes, there was lots of work to do. This need for complex software gave rise to software that helped shops create software.

The first part of this white paper explores the challenges and history of Synon-generated applications. Click here to jump directly to the technical aspects of Synon Escape.

Make it quick and easy!

Most AS/400 software is written in RPG. When the AS/400 was introduced RPG was just fully being realized as a business language and there were few developer tools available for it—writing AS/400 software was mostly done by hand. CASE tools and 4GL languages emerged to ease this application development pain. They aimed to speed up application development by abstracting away fiddly details to enable programmers to focus more on what needed to be done rather than how it needed to be done.

Shortly after the AS/400 debuted, several enterprise-aimed CASE products quickly emerged. Complex and sophisticated, these products enabled the creation of full-featured AS/400 applications. These products were aimed at large businesses with critical application needs, and, not surprisingly, large application development budgets. The investment in these tools could easily go into six figures.

The leader of the pack

Synon/2, by Synon, Ltd in the UK, quickly became the market leader in the AS/400 marketplace. Introduced in 1986 Synon/2 (which replaced a simple programming toolkit for the S/38 called Synon/1), quickly established itself as the leader of the pack. By 1997, Synon/2 for the AS/400 was called Synon/2E. Embraced and nutured by IBM, Synon/2E quickly established a worldwide presence and a loyal (and flush with cash) customer base. By 1997 Synon’s revenue was claimed to be $80 million with a claimed 6,000 customers around the world.

Synon provided tools to create and maintain a business-specific repository of business rules and data models. This repository is known as Synon’s “model.” Using Synon’s library of 15 pre-built program templates, Synon action diagrammer, and its business model, applications could be created and deployed quickly.

Synon’s output was RPG, which in turn was submitted to the RPG compiler to create AS/400 program objects. This generated RPG was output-only code—not meant to be changed or even seen by programmers. This RPG generation was essentially transparent to the Synon programmer. Any changes necessary to a Synon application were made to the Synon model and new RPG was generated.

For many AS/400 businesses Synon was a critical and important tool. It enabled creating applications in months with a small programming team. This is work that would typically take a large programming team, writing code by hand, years to create. More than 25+ years after their creation, Synon-based applications are still in use by hundreds of AS/400 (now know as IBM i) shops worldwide.

The benefits of Synon-based application development

Synon enabled the creation of countless applications and provided a substantial ROI for many AS/400 shops. Its benefits included:

• Generalizing the challenge. There is an old programming tenet that says programmers may create hundreds of programs but they create only a small, fixed number of types of programs. Part of Synon’s success was living out this tenet with its 15 program templates. These templates helped reduce the special-case challenges that needed to be resolved by hand.

• First class customization While Synon’s fixed number of templates resolved many challenges, some business needs simply can’t be addressed by universal templates. To overcome constraints imposed by its templates, Synon’s model is configurable with custom RPG and CL code as well as the ability to integrate free-standing (or existing) manually-created RPG and CL programs. Synon’s customization features stood it apart from its competitors and were used heavily by most Synon shops.

• Synon provides a library of very general-purpose functions. Date routines, programming messaging, logging, and many commonly-needed facilities are easily available and very frequently used.

• Standards and conventions. Synon’s 15 templates imposed predictable programming standards and conventions. This made program maintenance and changes easier. Undisciplined hand-written code (and most hand-written RPG is highly undisciplined) is much more challenging to modify than Synon’s predictable template patterns.

• AS/400 integration. Unlike many other program generators Synon exclusively targeted the AS/400. Synon applications exploited unique and specific AS/400 idioms and features to produce highly-tuned, performant applications.

The dark side

During its period of popularity and prosperity, Synon enabled the creation of highly valuable assets to AS/400 businesses. Alas, over the many years since their creation, those assets are rapidly becoming a business impediment. Enterprise applications are living, breathing entities. They need to be updated for myriad changing rules and regulations, they need new features added, and they need bugs fixed. The need to maintain and update, and even just keep running, AS/400 Synon applications today keeps many IT decision makers up at night.

Major Synon concerns

• Synon teams are reaching retirement age. Using Synon required a very specific set of skills. Many businesses trained and grew in-house Synon programming teams. However, many of these programmers are rapidly reaching retirement age and since Synon’s decline, there aren’t younger Synon programmers in the pipeline.

• Limited other Synon resources. At the height of Synon popularity there were many Synon-specific resources, contractors, and training available. Most businesses offering Synon resources have long-since evaporated or changed focus and the help that can be found is usually very expensive.

• Synon isn’t RPG. RPG programmers today are a precious resource, but not as precious as Synon programmers. Although Synon produced RPG, Synon was never about RPG–its generated RPG was simply an intermediate, unseen step necessary to produce native program objects from the Synon model. Therefore, even if a business can find RPG programmers, they aren’t likely to know any more about Synon than C# or Java programmers.

• Synon’s generated RPG isn’t usually an asset. Given that Synon generates RPG, it’s reasonable to ask “why can’t the application be maintained from that generated RPG?” That generated RPG was never intended for human comprehension. To humans, it is arcane, puzzling code absent any meaningful symbols—it was intended purely to submit to the RPG compiler and as-is offers no help in the persistence of the life of a Synon application.

• The cloud beckons. For many businesses, another reason to replace their old Synon application is to take advantage of the scalability, affordability, and ease of Azure-based cloud deployment. Migrating your Synon application to C# on .NET and the IBM i DB2 database to SQL Server opens up that possibility. ASNA Synon Escape can easily target an Azure cloud instance for head-ache free deployment and operation.

It’s not just Synon, it’s the platform

Beyond the issues a 25-year application, created with a now nearly-defunct generator, imposes on a business, the viability of the AS/400 as a 21st century enterprise platform must be considered. Now known as the IBM i, the IBM midrange platform has done a superb job of reinventing itself while maintaining high fidelity with very old applications.

The IBM i has many fans and isn’t going away anytime soon. However, the IBM i (and its predecessor models) is an aging computing platform with a native character-based green-screen user interface and an integrated, idiomatic database. Despite inroads by PHP and Node, RPG is still the primary IBM i language and most IBM i applications are still rooted heavily in it. RPG and IBM i operations and administration aren’t taught in very many colleges. For many IT decision makers today, especially those without years of devotion to the IBM midrange platform, keeping the IBM i is a hard sell.

Trapped in the Synon box

IBM i businesses using Synon applications today have very tough decisions to make. The unique business proposition they offer, the workflows that keep them competitive, and many day-to-day operations depend heavily on their Synon applications. For most businesses, moving forward without them is inconceivable. The path forward for these shops has but four alternatives:

1. Rewrite. This is the alternative that many IT decision makers want, that board members often thinks is best, and that has the most emotional appeal. Who wouldn’t want a shiny new application with all new modern conveniences and capabilities? Alas, this rewrite, for all intents and purposes, needs to be from scratch. IBM i application documentation (Synon or not) is almost always non-existent and/or woefully out of date. As romantic as the notion of rewriting the application is, the reality is that it takes a great deal of time (usually measured in years) and an exorbitant budget to get the job done. Rewriting the app is a game of beat-the-clock. Can you get the new app done before the old app expires?

2. Canned packages. Avoiding canned packages is why many businesses started using Synon in the first place. The need for a unique, custom-tailored solution had a much stronger pull than squeezing your business into a canned package. In the 25 years since that likely hasn’t changed. You may be able to identify and delegate general-purpose tasks like general ledger or accounts payable to canned packages, but those tasks that enable your business uniqueness, your competitive edge, can’t usually be done by canned packages.

3. Do nothing. This a favorite of IT decision makers who are desperately counting down the retirement clock. Why bite off the highly-visible task of replacing a 25-year-old app when it’s easier to ride out the next couple of years enduring the slings and arrows of jittery management? Soon it will all be someone else’s problem. This cynical view may be offensive to some but consider it carefully. Don’t let your management team be swayed by a decision maker who has more skills masking problems than solving them.

4. Migrate. An application migration transfers an application from one platform to another. While there are many discovery and investigative tasks, application migration distills down to domain-specific parsers that translate one language to another. For example, ASNA Monarch translates RPG to C#. However, Synon applications aren’t language-based, they are model-based. Traditional language-to-language migrations alone don’t work with Synon.

Cracking the nut on Synon migrations

For many businesses the need to escape from Synon’s grip is overwhelming and migration is the only rational choice. Ensuring the persistence of that Synon application for the business’s future is of paramount importance.

Synon presents several special-case migration challenges. Perhaps the biggest challenge is what was once a huge Synon strength: its first-class customization capabilities. Most Synon-generated applications are ultimately a mix of both pure, model-based Synon and custom RPG and CL. This custom RPG and CL exists embedded in the Synon model and in external (and hand-written) RPG programs.

In order to escape from Synon, the application must be taken to a native environment, either on the IBM i platform or some other platform. Migration vendors often take a naive approach to solving this puzzle. In some instances, the model is ignored, while in others it becomes the sole focus of the solution, ignoring the custom RPG and CL programs supporting the generated programs. There are primarily four ways to attempt a Synon migrations (as shown in Figure 1 below) but only one that makes sense.

Figure 1. The four types of Synon migrations

The summaries below assume a platform other than the IBM i is targeted for the migration (some of the reported weaknesses are diminished if the migrated application remains on the IBM i).

1. Migrate the Synon model to a new model and new generator. These tools attempt to migrate the Synon model to a new model. The most likely target with this approach is CA Plex (aka Obsydian) which is the cross-platform successor to the original Synon product. Weaknesses with this approach include:

   • The model import is imperfect and manual work is required to ensure its fidelity with the old model.

   • Custom RPG or CL embedded in the Synon model (and called using Synon’s EXCUSRPGM operation) needs to be rewritten. This is a significant weakness.

   • All reporting needs to be rewritten or replaced with a BI tool.

   • File IO that worked well natively on the IBM i may not be efficient with whatever database drivers (ie, JDBC) the target platform uses.

     The biggest challenge with the option above is its disregard for Synon dependencies of custom RPG and CL. These custom areas are crucial to the application and this approach not only leaves them behind but leaves you trapped by another generator.

2. Migrate the generated RPG to another language. This approach translates the generated Synon RPG to another language/platform. ASNA Monarch uses this approach and it works great for hand-written RPG applications. However, this approach does not work well with Synon-generated RPG.

   • The generated programs are very large with many segments of code repeated across many source members.

   • Synon-generated RPG didn’t use meaningful field and subroutine names (remember, this code was intended to be compiled, not read by humans.) Maintaining this incomprehensible code is nearly impossible.

3. Extract business rules and logic and rewrite the application. Using this approach, the Synon model’s business rules and logic are extracted (via a manual process) to a new and proprietary model definition. New application source, generally Java, is then produced from this model.

   This approach isn’t anything more than a moderately assisted application rewrite. It has all the problems of the #1 model-based migration but lacks a fully automated processes.

4. Model-driven refactoring of generated RPG. This approach is uniquely taken by ASNA’s Synon Escape. We feel strongly the best approach to modernize a Synon-based IBM i application is based on a model-guided translation of Synon’s generated code. The benefits of this approach include:

   • The refactored programs are based on a framework that consolidates the common functionality of the Synon templates and its unique framework.

   • The resulting application is maintainable, modern, and object-oriented C#. Significant differences between the original generated RPG and this refactored code are:

     • Meaningful field and subroutine names are mapped to Synon’s gibberish names.

     • The generated code is easier to comprehend and lends itself to easier refactoring

     • C# framework with class hierarchies implementing the otherwise repetitive code of synon functions.

   • Faithful implementations of Synon’s original 15 templates.

   • Custom RPG or CL is migrated with ASNA Monarch directly.
   • High-fidelity runtime replacements for IBM i idioms such as activation groups, data areas, QTEMP, and output/job queues.

With ASNA Synon Escape, the old application is expressed in a new programming language targeting a new platform. All functionality, including user interfaces and reports, are functionally equivalent to the original application. The custom RPG and CL that integrated with the old Synon application are also migrated directly as modern C# and integrate with the new application.

A future-proofed Synon application migration should:

• Have high fidelity with all parts of the existing application (including reporting, interfaces, business rules, and database access).

• Extract the value of the Synon model but also ensure that the migrated application can be maintained and understood without it.

• Not exclude or ignore custom RPG and CL that integrates your business’s “secret sauce” with the original application.

• Promote the new application to its new platform not just to run, but to be rationally extended and maintained with standard tools and techniques.

ASNA Synon Escape does all that. And much more!

A look at Synon Escape’s technical details

Synon Escape is ASNA’s Synon-specific application migration suite. Although Synon Escape is a relatively new product it shares and uses many components from our proven original migration suite, ASNA Monarch. Monarch migrates hand-written RPG to C#. Over the last couple of years we’ve tried a couple of approaches to squeeze Monarch into the task of migrating Synon applications. However, it was clear that Synon needed something very specific and Synon-focused.

Using a model-driven approach, Synon Escape migrates Synon2/Cool:2E/CA 2E applications to C#. By coupling the business logic definitions in the Synon model with Synon’s generated RPG, Synon Escape creates rational and maintainable C# source. Most Synon migrations aren’t just Synon migrations. They are hybrids needing both Synon-generated and custom RPG and CL code migrated. ASNA Monarch makes a great partner with Synon Escape enabling ASNA to effectively migrate both an application’s Synon model-related code with Synon Escape and its custom RPG and CL with ASNA Monarch.

Synon Escape shares Monarch’s migration console, ASNA Cocoon, shown below in Figure 2. The Cocoon analyzes IBM i library contents to create a repository of cross-referenced application information.

Figure 2. ASNA Cocoon showing application assets

Some of the information the Cocoon reveals is:

• An inventory of application assets (ie, physical and logic files, data areas, program objects, copy books, printer files, source members)

• Dependency graphs (what objects call other objects)

• Old and likely unused program objects

• Missing source members

The Cocoon provides a detailed program object call-graph, shown below in Figure 3. Program groups are identified to create a detailed migration road map.

Figure 3. A Cocoon call graph showing application dependencies

Synon-specific modules snap into the Cocoon to help with model discovery and definition. Synon Escape’s field mapping, shown below in Figure 4a, is one of the ways Synon Escape creates maintainable C#. These meaningful field names, derived from the Synon model, dramatically increase code readability and maintainability.

Figure 4a. Synon Escape's field mapping

The result of Synon Escape’s field name mapping is shown below in Figure 4b:

Figure 4c. The results of Synon Escape's field mapping

To do the heavy lifting of actually transforming code, Synon Escape uses a variety of “migration agents” as shown below in Figure 5:

Figure 5. Synon Escape's Migration Agents

• Display File Agent. Display files are migrated to Microsoft ASP.NET Razor pages. At runtime, these pages render as HTML 5.

• CL Agent. CL is migrated to C#.

• RPG Agent. ILE RPG and RPG/400 is migrated to C#.

• Printer File Agent. Printer files are migrated to a Windows style print file. These faithfully recreate the print file as it existed on the IBM i.

• Message File Agent. Message files are migrated to an XML-based rendering.

• Data and Schema Agent. The IBM i DB is migrated to SQL Server. Physical files are transformed to SQL tables and logical files are transformed to SQL views. Once migrated to SQL Server, all of its business intelligence features can be used against this new database.

As the Synon-generated RPG is migrated to C#, the code is refactored to eliminate its intrinsic redundancies. An example of this refactoring is shown below in Figure 6:

Figure 6. Synon Escapes refactors code redundancies

Synon Escape creates ASP.NET pages which render as HTML 5 pages. A before and after screen is shown below in Figure 7. As a post-migration step these new screens could be further enhanced both functionally and cosmetically.

Figure 7. Synon Escape UI before and after screens

Summary

The need to migrate your Synon application goes well beyond being a technical issue. Locked inside that application are the custom processes and workflows for how your business delivers its unique business value. Without persisting those custom processes it’s nearly impossible to persist your business.

ASNA Synon Escape is a rich and deep solution than enables escape from your Synon IBM i dependencies. Having moved your legacy Synon application (and its custom RPG dependencies) to C# doesn’t just offer escape, it hands that application off to a younger (and vastly more available) programmer community. Once migrated to rational C#, there is no end to the ways the application can be further enhanced and extended.

Synon Escape stands alone in its ability to protect your business by persisting your critical legacy application well into the future.