With a broad sense of your RPG challenge, start laying the groundwork now
for charting your business’s RPG future-proofing plan. Even if your shop may
be one of the lucky ones with a younger RPG team, challenging decisions lurk
and it’s not too early to start understanding and preparing for them.
RPG applications don’t live in a vacuum. They live in an ecosystem composed
of custom non-RPG code, third-party applications, and additional hardware.
Other facilities such as job scheduling, bar-code scanning, Web servers, EDI
processing, and business partner integrations need to be considered.
Do a deep dive into all of your critical technical dependencies. You need to
understand exactly where these kinds of things overlap with your existing
RPG applications and workflows. Transforming your RPG application means
transforming these stacks as well.
While addressing your RPG dependence is a tough, challenging thing to do,
it’s also an opportunity. Over the years, in the effort to answer rapidly
increasing business demands on a 20 or 30 year-old system, many IBM i
shops have added many complex technical layers atop their RPG applications.
These layers often quickly prove to be brittle and unstable systems (One
IBM i manager recently told us his organization’s large IBM i
installation was “built on a house of cards.”)
Assessing how to transform your RPG application also gives you the chance to
assess how to improve years of brittle, tacked-on layers. Migrating your RPG
applications to .NET and C# offers a full-stack platform that paves the way
for long-term persistence of your RPG applications—and provides a much
better alternative than band-aid fixes.
Transforming a decades-old RPG application with hundreds of thousands of
lines of code is a big job. However, the actual process of mechanically
converting RPG to another language is actually pretty direct. The real
challenge is transforming that RPG to something that can gracefully deal not
just with the RPG but with IBM i/RPG idioms. RPG programs dependencies
are idioms such as:
These, and many others, are all areas of your RPG that are easy to take for
granted until it comes time to replace them. As you consider the future for
your RPG source code, these idioms must be accounted for.
ASNA has specialized in IBM i application migration for more than 15
years and can help you with every aspect of migration. Our process-driven
methodology helps discover not just RPG issues, but also reveals other
application exposures before migration even starts.
A primary hallmark of a successful migration is no surprises. You
don’t want to be deep into a migration to all of sudden realize that you
don’t have the source code for a critical module. We feel strongly that an
application migration should not begin until all of the potential roadblocks
and unknowns are discovered and resolved.
Before we attempt to migrate any code we perform deep analytics on
your code base to understand its dependencies, identify areas in the code
that might be remediation, and many other metrics. This information enables
us to fully understand your application and its scope.
Our four-phase migration methodology, outlined above in Figure 1, drives the
application migration. Our goals are:
The decisions about the persistence of your mission critical RPG
applications are among the most important decisions you’ll ever make for
your business. We’ve presented many facts and more than a few opinions in
the articles on this site. You may agree or disagree with our opinions.
For the time being, though, let’s put opinions aside. Let’s consider three