ASNA Monarch is a full-featured analytical/migration suite that migrates existing IBM i RPG applications to .NET using either IBM i DB2 or MS SQL Server. Monarch includes a sophisticated analyical component that helps plan migrations and migration "agents" that bring your RPG, your CL, and your DDS to .NET. Monarch produces ASNA Visual RPG or Microsoft C#.

Target ASNA Visual RPG or Microsoft C#

Monarch can produce either ASNA ASNA Visual RPG or Microsoft C# from your RPG. The target language you select depends on your business and your application evolution strategy. There are typically two schools of thought on this subject, generally defined by the trajectory of your existing RPG programming team.

If your RPG team is years away from retirement (and many RPG teams are!) then it may make sense for you to use Monarch to produce ASNA Visual RPG. This keeps your RPG programming team, probably the team who originally wrote the legacy application in the first place, in charge of its modernization effort.

If your RPG programming team is nearing retirement age, it may make sense for you to use Monarch to produce C#. This puts your long-held legacy RPG application in the hands of younger C# programmers and is, for many shops, a very good strategy.

No matter which you choose ASNA Monarch you make the choice.

Use either IBM i DB2 or Microsoft SQL Server as your migrated application's database server

ASNA Monarch connects through ASNA DataGate to an underlying database server. This server can be either the IBM i (using its intrinsic DB2 database) or Microsoft SQL Server. The latter is generally the target when the business goal is to use Monarch to migrate entirely off of the IBM i platform. However, many shops use Monarch not to migrate off of the IBM i platform, but to be able to migrate their RPG apps to .NET for further enhancement and customization.

ASNA Datagate makes the database selection transparent to the migrated application. You could migrate an RPG app with Monarch and initially connect to the IBM i, but later point the app to SQL Server (assuming the database has been migrated to SQL Server). This is part of Monarch's staged approach to application migration that enables you to incrementally migrate your app to .NET.

Once again, no matter which you choose,  with ASNA Monarch you make the choice.

The Monarch Cocoon—where the application transformation originates

The ASNA Monarch Cocoon's high-level view

The ASNA Monarch Cocoon is a .NET application that interrogates specified IBM i libraries for programs and program dependencies. You use this information for discovering program dependencies, analysis, and migration planning. The Cocoon provides information such as:

  • Program call graph – to spot program object dependencies on other OS/400 program objects (i.e., called programs and system APIs)
  • Cross-referenced object usage – to identify what programs use what objects (such as files, data areas, etc.)
  • Host RPG source view – to take a quick look at the underlying host source code
  • Density factors – to provide the metrics on the “migrateability” of any given program. These factors help you plan and allocate migration resources
  • Notes display – a “diary” area to record notes about each object discovered

The Cocoon produces dependency graphs showing exactly what the various dependencies are in your IBM i RPG application. It also shows information such as which objects have source missing, which program objects are infrequently (or never) called, and what objects appear to be out of date with their source code.

Monarch Gameplans—specifying your migration strategy

The Cocoon shows dependency graphs
of IBM i program objects

Monarch Gameplans define a program or group of programs you want to migrate. You generally create a Gameplan for each application or application section you migrate with Monarch. A Gameplan specifies program attributes such as library lists, the program entry point, and the active database platform.

 

The graphical ways that Monarch presents IBM i objects and dependencies provide the tools you need to create rational gameplans. This analytical work is very important to a successful migration. Once you established migration plans with the Monarch Cocoon, migration is much smoother.

 

Monarch analytics in action

In Monarch parlance, a cluster is a group of groups. Clusters can be determined by a number of ways, but a common way to determine them is to identify natural clusters. A natural cluster is formed starting at a single entry point program and combining only those programs that can be reached by following the call graph. Programs are typically migrated by cluster group. The challenge with large, complex RPG programs is identifying what is the entry point for a cluster. 

What is assumed to be two migration clusters
It is often assumed that using IBM i menu options is a good way to define cluster entry points--but that is often incorrect. Consider a menu with two choices, the first of which calls program A in cluster A to left; the second of which calls program U in cluster B. You can also see that programs A and U also make various program calls during their life cycle.
Monarch reveals that cluster B
has a dependency on
program F in cluster A
Monarch's analytical components reveal that program V in cluster B makes a call to program F in cluster A (as indicated with the red arrow to the left). This indicates that identifying the clusters directly off of menu options isn't as simple as it seems. Submitting cluster A and cluster B for migration as defined here could cause migration issues because both clusters include program F and the programs it calls.
Monarch shows that what was
assumed to be two program
clusters is really three clusters.
Using Monarch dependency graphs, a third-cluster, cluster C, is identified. It gets migrated first, and then clusters A and B get migrated. This way, cluster C is already migrated and ready to be shared by its two parent clusters (as indicated by the green arrows to the left). Exactly how cluster C gets migrated depends on what cluster C does. If it doesn't use any display files, it would most likely be migrated as a .NET class library. Alternatively, it would migrated with its interactive capabilities available.