New Option Emerges for Refactoring IBM i Apps

August 19, 2020 Alex Woodie

IBM i shops that want to refactor their RPG and COBOL applications into different languages have a new option available to them. In late June, Astadia and Blu Age announced they’re working together on a new service that automates the conversion of customers’ older apps into Java and .NET code that can run on X86 systems in your basement or the cloud.

Based in Boston, Massachusetts, Astadia claims to have completed more than 200 mainframe migrations and more than 100 mainframe modernization projects over about two-and-a-half decades. The company has modernized millions of lines of COBOL code running on mainframes from IBM and Unisys, and it’s familiar with just about every COBOL compiler on the market.

Astadia recently tapped Blu Age of Plano, Texas, to provide automated code refactoring. Blu Age develops what Astadia’s Dave MacSwain says is the market’s top code refactoring tool. Dubbed the Blu Age Modernization Factory, the software automatically converts code written in languages like RPG, COBOL, PL/1, CL, and PowerBuilder into Java or C#.

For IBM i shops, it’s about fundamentally changing clients’ technology to give them more deployment options, says Jeff Shelby, Blue Age’s director of business development.

“What we allow people who have iSeries to do is to take the IP [intellectual property] they’ve developed over all years in the business applications they have, and to move those over to the cloud or on-prem using modern .NET or Java, turning them into n-tier applications with a presentation layer, a service layer and a data layer–all those things you need, and all those things that people that come out of college understand how to program in,” Shelby tells IT Jungle earlier this week.

As part of the refactoring, the customer has the option of continuing to use the Db2 database, or moving to PostgreSQL (favored by folks moving to Java) or Microsoft SQL Server (favored by the .NET crowd). Blu Age handles Db2 database conversions too, regardless of whether the client uses record-level access or SQL.

For the presentation layer, the 5250 screens from IBM i applications are converted into Web screens based on Angular and HTML5. Like the refactoring of source code, the screen upgrades are one-to-one conversions from the old system, with a focus on replicating business function; it’s up to the clients to spruce up screens and functions after the fact.

When a client signs up for a code refactoring engagement, the first thing Blu Age does is run the code through the company’s patented technology (obviously the customer must have access to the source code to do this). The company generates a knowledge model based on the initial code analysis, which is expressed in Unified Modeling Language (UML). The final code (either Java or C#) is then generated from that UML model, Shelby says.

Blu Age claims that it can automatically convert 100 percent of a customers’ COBOL, RPG, and CL code, as long as it’s standard code, Shelby says. If that seems like a high number, it’s because Blu Age approaches every engagement as an opportunity to improve its own software.

“The reason we do 100 percent is because we’re going to change the model,” Shelby says. “If there’s anything my technology doesn’t recognize, I’m going update my technology. If there’s an RPG call I’ve never seen before, my engineers are going to go in and change that transmodeling process. They’re going to take the RPG verb and figure out what it means and figure out how to turn it into a business function.”

The BlueAge Modernization Factory

Things rarely go entirely smoothly in migrations, of course. Anybody who’s been involved with moving an enterprise application from one platform to another understands the difficulties that invariably arise. Blu Age, to its credit, seems to understand that (not all companies in the re-platforming business for IBM i do). That’s why it dedicates the lion’s share of the code refactoring process to testing.

“We don’t enter these lightly. These can go south if you’re not prepared and people don’t understand it,” Shelby says. “We always do a POC or a pilot before we take any engagement. We break it down and do the analysis, because at the end of the day, we’re going to do the modernization piece for a fixed price. And if I don’t understand what it is, and if a customer doesn’t understand their part of it, we’re not going to get it done in the duration and under the budget it needs.”

It’s critical to take a complete inventory of the application early in the process. These analyses typically reveal surprises and potential gotchas, which is why it’s so important to identify them up front. “You look for those pieces that are really complex, looking for the strange things that everybody has,” Shelby says.

Once Blu Age breaks the code down into domain subsets and identifies the commonalities, it can pinpoint a starting point for the code refactoring itself. The company begins work on domains independently, which allows the client to test smaller chunks of code and provide feedback to Blue Age to help subsequent domain conversions go more smoothly.

Astadia’s role in these engagements is to provide project management and assist with testing. “Testing is a big deal,” says MacSwain, who works in the office of the CTO at Astadia. “Testing can be 40 percent to 50 percent of an application migration. We’re pretty good at testing, so we’ll take over the testing aspect, and in some cases, project management and program management. But the core technology that actually does the transformation of the code is supplied by Blu Age.”

The longest part of client engagements is always the testing and verification process, Shelby says. “Even though we’re doing functional equivalence, which allows them to test at a macro level, it still takes some amount of time to do the testing on these complex application,” he says.

Once you open up the code, expect the unexpected. That is why Blu Age uses code coverage tools to measure how much of the modernized code is exercised during testing. Once, while migrating a mainframe application for an airline, Shelby was dismayed to see that during initial testing only 25 percent of the modernized program was validated during testing. After analyzing the situation, his team realized that about 70 percent of the application’s codebase was dedicated to one very important if rarely used business function: dealing with employee absences due to weather delays. The airline then supplied new test cases that resulted in this business condition being completely validated.

“It doesn’t happen very often, but when it does happen, all kinds of things have to happen,” Shelby says. “It’s those kinds of things that you learn along the way, as you make sure that you have good test cases and the code is covered.”

Over the years, Blu Age has migrated about seven companies off the IBM i server in the United States and another four in Europe, and it currently has a handful more at various points in the pipeline, according to Shelby. Demand has picked up for IBM i migration in recent years, he says. Companies want to get to the cloud, or at least be ready to move to the cloud.

“The iSeries modernization market has exploded over the last three years,” he says. “It went from very few people trying to do anything. It’s probably the most new business that comes our way. We have people reaching out to us almost every week about some sort of iSeries modernization.”

The length of time required to complete an IBM i modernization depends on the target platform. Shelby says one million lines of IBM i code can be migrated to Java in about a year, while it would take about 18 months to migrate to .NET and C#.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search