Monarch's analytical components use a combination of objects and source members as inputs. However for the actual code generation phase, Monarch uses a variety of source members as inputs when migrating an RPG application.
- ILE RPG/RPG III. ILE RPG and RPG III (aka RPG/400) is migrated to either ASNA Visual RPG or Microsoft C#.
CL. Virtually every meaningful RPG program uses at least a little CL and many use lots of CL. Monarch migrates the CL that manages RPG application coordination (with commands such as
OVRDBF) to either ASNA Visual RPG or Microsoft C#. Monarch documentation provides more detail.
- Display file DDS. Monarch migrates interactive RPG programs as browser-based ASP.NET applications. Monarch uses a display file's DDS display file specification to create a corresponding ASP.NET ASPX Web page.
- Print file DDS. ASNA DataGate provides print files similar in function to IBM i print files. Monarch uses a print file's DDS print file specification to create a corresponding DataGate print file.
- RPG source printer O-specs. When Monarch encounters program described print files (via RPG O-specs) it collects the O-specs and uses them to create a corresponding DataGate print file.
- Message files. Monarch migrates message files to DataGate message files (which is essentially an XML-based version of the message files).
Monarch works with IBM i (aka OS/400) V5R4 and up.
We have many customers who use Monarch not to migrate off of the IBM i platform, but rather use it to make it easier to add functionality and capabilities to their legacy RPG application portfolio. Once migrated to .NET (with either ASNA Visual RPG or Microsoft C#) you can exploit all of the capabilities of the .NET Framework to dramatically add power to your application. For example, you can easily integrate it with business partner Web services, connect it to Microsoft Office products such as Excel, or easily use alternative input devices.
ASNA Monarch doesn't provide a COBOL migration agent. The impact of this depends on whether you're using the IBM i or Microsoft SQL Server as your Monarch application's database server. If you're using the IBM i, the COBOL program can't be migrated but it will still operate appropriately with ASNA's browser-based terminal emulator, Browser Terminal. If you're using Microsoft SQL Server as your database server, you'll need to find a .NET-based replacement for the COBOL application before you can migrate 100% off of the IBM i.
Monarch migrates ILE RPG or RPG III (aka RPG/400), but it cannot migrate RPG II. The primary issues here are RPG II's program-described disk files and application design that makes heavy use of multi-format files. RPG II program-described files will need to be converted to RPG III with externally described files. Depending on how they are used, multi-format files may also need to be split into distinct file objects. Monarch's conversion tools don't directly address these issues but the ASNA Services Team does have experience refactoring and converting such code if necessary.
For most RPG applications, you can count on Monarch to migrate at least 90-95% of your RPG without issue. However, there are occasionally RPG idioms and/or conventions that need to be remediated before the migrated code compiles with Visual Studio. A classic example of this is the old RPG practice of using a
GOTO in a subroutine to pass program control back to the RPG mainline code. This sort of issue needs to be resolved by hand before the migrated project will compile. Monarch's Cocoon provides good analytic metrics on issues like this to help determine how much remediation effort a migration will require.
Monarch's RPG input is RPG/400 or ILE RPG source. If you have the RPG, independent of how it was generated, Monarch can migrate it.
Virtually every meaningful RPG program uses at least a little CL and many use lots of CL. Monarch migrates the CL that manages RPG application coordination (with commands such as OVRDBF, ADDLIBL, CHGDTAARA, CALL, OPNQRYF, and OVRDBF) to either ASNA Visual RPG or Microsoft C#. Monarch documentation provides more detail.
ASNA DataGate faithfully implements the IBM i's concept of print files. DataGate print files provide the same record format idiom that traditional IBM i print files do. Because DataGate print files are generally printed on laserprinters, you can add further customize DataGate print files with enhancements such as bar charts, images, and graphs
Monarch converts print file DDS specifications into DataGate print files. Monarch is also able to extract program-described print file formats into DataGate print files. After migration with Monarch, the RPG that directed output to a traditional print file works in the same way but rather directs the printed output to a DataGate print file.