ASNA Monarch: Benefits and Features
We felt that ASNA Monarch had the best offering for our long-term business needs. The initial costs were competitive and in the end we’d have a version of Navixa running under .NET and have the option of later using Microsoft’s SQL Server as its database.
Monarch Benefits
- Monarch puts your estate RPG application in younger hands. Green-screen RPG talent is increasingly harder to find. By hosting your legacy application in .NET, you protect the future not just of the application, but of your business. Once migrated to .NET, a new generation of .NET programmers can nuture and care for your application..
- Monarch does much more than transform RPG. RPG programs don’t live in a vacuum–so ASNA Monarch is able to migrate not only your RPG/400 or ILE RPG code, but Monarch also migrates the CL, display file DDS, print files and message files.
- Monarch migrates your IBM i DB2 database. For full platform-to-platform migrations, ASNA Monarch can also migrate your IBM i database to MS SQL Server. Because Monarch uses ASNA DataGate, your existing record-level RPG needs minimal modification to work with SQL Server.
- Staged modernization/migration. ASNA Monarch can work cohesively with ASNA Wings to provide a staged modernization/migration strategy. This means Wings can be used in the early stages to deliver a modernized UI and then as the project progresses Monarch can migrate business logic to .NET.
- Gives your app’s UI a modern boost. ASNA Monarch applications have a browser-based presentation–implemented with .NET’s ASP.NET programming model. This presentation layer can be modified and enhanced with standard Web development techniques.
- Analytical tools included. Monarch provides the tools needed to create a rational application migration roadmap. Legacy RPG applications are often very large (with usually more than 1 million lines of RPG). These large applications are very challenging to migrate successfully, and without a good map, success is very elusive! Monarch provides dependency and call diagrams, as well as application metrics needed for a successful migration.
- ASNA migration services available. ASNA Monarch can be purchased outright and the work performed by your team or ASNA has a highly-trained team of application migration specialists who can help you with any or all stages of your application migration.
Monarch Features
The Monarch Cocoon—where the application transformation originates
The ASNA Monarch Cocoon is a .NET application that interrogates pecified 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:
The ASNA Monarch Cocoon is a .NET application that interrogates pecified 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 nderlying 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 witht heir source code
In short, the Cocoon provides the single source of truth that guides the application migration.
Monarch Gameplans: Specifying your migration strategy
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 identify 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.
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 identify 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.
IBM i DB2 or SQL Server — your choice
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.
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.
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’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.
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.
