ASNA Brings RPG to .NET Migration Software to Latest Windows IDE

June 10, 2008 Dan Burger

IBM iSeries and System i shops have been migrating RPG code to the Microsoft .NET environment for years. It’s not happening because it makes no sense. For a lot of organizations, it’s the right thing to do. Making it quicker and easier is why ASNA, the application development tool maker with more than 25 years experience in the AS/400 market, develops a product called Monarch. ASNA has just released a new version of Monarch, Version 4.0, with plenty of enhancements worth noting.

Monarch 4.0 supports Microsoft’s .NET Framework 3.5 and Visual Studio 2008, which were released earlier this year. Monarch 3.1, the previously current version, supported .NET Framework 2.0 and Visual Studio 2005. Although Windows programmers have been somewhat slow to move to the new framework and development environment, the momentum for change is inevitable. Monarch 4.0 also supports .NET Framework 2.0 and Visual Studio 2005, which is where the bulk of Windows programming is done and where most Windows programmers are comfortable for now.

On the RPG side, Monarch 4.0 brings a few more conveniences to the software party. The first is a capability to automatically recompile old RPG code that makes use of the RPG cycle. This is code that likely dates back to System 34 and System 36 days. In most cases it was converted to RPG II during the early AS/400 years. ASNA has run into this with customers often enough to include the automatic conversion in this latest release.

Additional automation has also been included for the conversion of embedded SQL to .NET. This was another area (like the RPG cycle mentioned above) where hand coding was previously required. Now a high percentage (ASNA estimates it at 90 percent) will transfer without any issues. In most cases, the embedded SQL is straightforward code. That doesn’t guarantee that variations won’t cause recompiling glitches, however.

In terms of migrating DB2/400 data to SQL Server, Monarch 4.0 has a feature that examines DB2/400 database files and provides a migration assessment that details which files will transfer easily and which files will be more difficult and require manipulation when going to SQL Server.

ASNA’s middleware product called DataGate provides the capability to communicate with both the DB2/400 and the SQL Server databases.

ASNA officials feel comfortable promising that Monarch can handle RPG to .NET migrations with 95 percent of the recompiling done automatically, but they readily admit that much of this has to do with the style of the original code.

“Things that make it more difficult, for instance, are the use of pointers and user spaces,” says ASNA President Eduardo Ross. “They don’t come across directly.”

In the big picture that has to be considered in application modernization projects, these “hiccups” requiring hand coding are minor. “When you think about an application that has 2 to 4 million lines of code, getting 95 percent of that coming across automatically is a huge return on investment,” Ross points out.

The .NET environment, in Ross’ view, is worth the migration because it allows applications to do things that are typically complicated on the System i side.

“Integration to the outside world with Microsoft Office or Web services or being able to talk with other applications becomes almost trivial from the programming side,” he says. “If you want to consume a Web service on the ‘400, it gets sticky because you cannot do it within the realm of RPG.”

Expectations for 100 percent of RPG code to be recompiled should not be entertained. That’s not a knock against ASNA. It’s a realistic view regardless of what’s being recompiled or the method being used. Ross still insists almost all the program logic is preserved. If there’s a problem it’s that the syntax may not automatically come through.

“If you have complex business logic, for instance in pricing, sometimes the logic that generates a price for a specific order is very complex–depending on items, customers, and backlogs, all of that is easy to migrate because it is pure business logic,” Ross says.

During the migration of the application presentation layer, Ross says, the layout of reports and screens can be preserved.

The migration process begins when the Monarch software is pointed to an application using one or more sets of libraries on the System i. Monarch analyzes the objects it finds in those libraries. It determines the relationship between those objects. For instance, program to program calls are significant. It identifies which programs are using which files and determines whether the program is interactive or not.

Monarch then creates groupings, or sections, of those programs. There could be, for instance, 5,000 programs. In order to do a cohesive migration, it’s necessary to effectively groups programs.

The migration occurs when these groupings are brought across and display files are converted into Active Server pages. The person doing the migration then opens the project in Visual Studio and compiles it, resolving unsupported features (pointers and user spaces, for example) when necessary. If the application consists of several thousand programs, they will need to be assembled with Windows-type tools and techniques.

Applications can be enhanced in the Visual Studio IDE by using tools from ASNA’s Visual RPG, or from Microsoft’s Visual Basic or C #. Each one generates the same type of executables, meaning they can call one another. ASNA’s Visual RPG is the best bet for RPG programming tools that make the most sense to RPG programmers.

“There are some decisions and work to be done to get the applications working on the other end,” Ross says. “Compared to the alternative, this work is small relative to rewriting an application from scratch.”

Ross’ willingness to talk about hand work and the realities of what won’t happen at the touch of a button is refreshing in an industry where selling unrealistic expectations is the norm.

“When you talk about percentages,” Ross says, “you have to decide whether you are talking about percentages of features or percentages of lines of code. Of all the features in RPG, what percentage of these seldom-used features affects the total number of lines of code? What is important is whether the feature affects 20 lines of code out of a million.”

The RPG support for print programs that comes in Monarch 4.0 is a good example. Some companies don’t use it, and the feature is of no value to them. However, if a company uses print programs and Monarch 4.0 supports it, the recompiling automation of those programs becomes a big deal.

Ross provided the example of a company that had 550 programs (10 percent of the company’s applications) that used the RPG cycle. It’s possible that removing the cycle from one program by hand would take four hours. That’s 2,000 hours total. The automation of recompiling these programs in Monarch 4.0 saves that effort.

“Every percentage point that we gain in terms of automatic compiling represents potentially huge savings compared to the hand work involved for the customer,” Ross says.