Technical Overview of Monarch

Tightly coupled with other ASNA .NET technologies, ASNA Monarch migrates green-screen RPG to ASNA Visual RPG for .NET. Once migrated, you compile that code with ASNA Visual RPG's compiler. You are in full control of the project along the way. And, after migrating a project, you can easily customize and extend that project in a number of ways that benefit your organization and your development teams. Improved usability with better graphical user interfaces, increases in programmer productivity with Visual Studio, and enabling more persistent integration with other front and back office applications are just a few of the benefits.

Uniquely positioned

Monarch distinguishes itself from other simple-source translators in a variety of important ways:

1. Monarch does not convert RPG code to a new, unfamiliar language.
   While other products attempt to translate RPG into C# or Java, Monarch converts all iSeries/i5 RPG/400 and RPG IV fixed and free source code into RPG for .NET. Monarch's RPG is compiled with ASNA Visual RPG for .NET to create 100% verifiable Microsoft Intermediate Language (MSIL) binaries, creating a contemporary development environment that is maintainable by both RPG and object oriented programming teams.
2. Monarch migrates more than just the program source code.
   Using its Migration Agent technology, Monarch converts collateral, yet important, parts of the application (including CL, Display Files, Printer Files, Message Files and Data Areas) to provide a full migration of the application. Monarch even implements the program message queue.
3. Monarch provides its own comprehensive OS/400 program object discovery process.
   To ensure the migration process is effective and includes everything necessary, Monarch provides its own OS/400 object inspector-that communicates directly and in real time to the iSeries/i5.
4.  Monarch optionally converts AS/400, iSeries, System i5 data into Microsoft's SQL Server.
   This capability is another reason Monarch is truly a full-featured modernization solution. Employing ASNA DataGate for SQL Server, the Visual RPG applications continue to use the familiar RPG data access operation codes like CHAIN, READE, READP, COMMIT, ROLBK. There is no SQL substitution in the programs!

Product and Process Overview

Once the scope of the transformation project has been set and the organization has committed to follow through on the migration, then the Monarch Migration Process can be set in motion. This process consists of four main steps.

1. Object Inspection: detailed information about all of the OS/400 objects involved)
2. Visual Analysis and Strategy Generation: process used to determine how different OS/400 objects will be transformed to the equivalent .NET components
3. Source and Data Migration: the actual migration of the application or programs is performed
4. Unsupported Features Resolution: detect and resolve any problems while transforming the RPG objects into .NET components

Object Inspection

Using Monarch, under the workbench Cocoon, an application known as the Collector (running on the As/400, iSeries, or System i5) investigates the application to identify the OS/400 objects and present them in an Object Gallery. Objects include:

• Menus
• Programs
• Modules
• Database Files
• Display Files
• Printer Files
• Data Areas
• Message Files

Visual Analysis and Strategy Generation

Cocoon organizes the Objects in the Object Gallery by type and provides several analysis tools to better visualize the Application as a whole.

The Object Gallery may be broken down into several GamePlans to facilitate object migration and re-use (redundancy avoidance). Each migrated GamePlan constitutes a Visual Studio/Visual RPG Project.

One or more entry points define a GamePlan and each entry point is a Program that can be called from other Programs, Menus or the command line. The GamePlan includes not only the Programs called by the entry point Program(s), but also all other objects used by the Programs involved.

Each GamePlan has associated with it a set of properties, including a Project Type, a Name and a Location. These properties are used to create a Visual Studio Project where the Subsystem will be crystallized.

Having good analytical skills and a deep knowledge of the application and its relationship with other applications will help in determining the best way to partition the Programs into GamePlans.

Each Object in the GamePlan contains a Directives page containing pertinent information to be used in the next step (actual Program and data transformation). The collection of all of these decisions will form the aggregate representation of the Migration strategy.

Cocoon allows both the Object Gallery and the GamePlan to be opened and made visible at the same time. Drag-and-drop operations to organize objects are available to the Migrator. The state of the Visual Analysis session persists in the form of a Migration Solution.

To create a GamePlan, an entry-point or top-level Program is selected from a Gallery and a Library List is supplied. The Cocoon will crawl thru the object reference web to determine all objects forming the Subsystem. This information is the basis for the initial content of the GamePlan. If a GamePlan turns out to be too big or cumbersome to manage as a single entity, it is possible to partition it by pruning a branch from the call graph and creating a new, smaller GamePlan out of the branch. Cocoon will then place a reference where the branch used to be pointing to the new GamePlan.

Source and Data Migration

Once the migration Directives are defined in the previous step, the actual migration of the Application is performed by selecting Cocoon's GamePlan - Migrate menu option.

Several Migration Agents will run to convert each object in a GamePlan to its final Windows .NET form. Each Agent will use the Directives defined for each object during the previous step.

The whole process will be logged in detail and Errors will be separately logged to assist during the conflict resolution step.

There are multiple agents used to Migrate specific object types and one agent responsible of creating the Visual Studio Project and Solution. This diagram shows the agents with their inputs and outputs:

Unsupported Feature Resolution

The Migration Agents will likely detect some problems while transforming the Legacy objects into .NET components.

Migration Logs, generated by Monarch can help determine how to resolve problems reported through the process.

Migrated objects are now managed as a Visual Studio project, where development teams can begin modifying the Projects and sources and adapting the code to the .NET platform on those features that are unsupported by either AVR or .NET. Examples of these include usage of Cycle or of ICF files. This is also the perfect stage to eliminate any code that is irrelevant in the new environment.