Knowledge Is Power When Assessing Your IBM i Legacy

October 29, 2012 Alex Woodie

The IBM i platform can be both a blessing and a curse to you, the IBM i customer. While its integrated nature and reliability insulates you from tasks and expenses commonly faced by users of mainstream platforms, the “black box” and its longevity also tends to mask problems that may be lurking in your RPG code. So it’s not surprising that when you evaluate how to modernize your IT system, the lack of visibility into the inner workings of your system can lead to fear, panic, and, ultimately, uninformed decisions.

It is interesting to note how the IBM i platform’s conundrum came to be, and how a strength evolved into a weakness. IBM created an amazingly integrated system that was fairly simple to program in RPG, at least compared to the Unix systems of the day. Many companies in the 1980s and 1990s invested heavily in RPG programming, and developed first-rate applications for a variety of industries. Some of these programs turned into packaged ERP applications sold by ISVs, and the whole midrange ecosystem flourished.

Then in about the year 2000, something curious happened. After billions of dollars were spent modifying OS/400 applications to handle the Y2K date change, IBM investment in RPG came to a halt. Object-oriented programming languages like C++ and Java became the hot new thing, and IBM responded by pushing Java into the AS/400 customer base. But when the big Java push flopped, IBM basically did nothing on the language front. It did make improvements to the IBM i operating system, database, and middleware, but it certainly didn’t reinvigorate its investment in procedural RPG. While IBM i programmers loudly called for more RPG, IBM simply refused to double down on a 40-year-old language. (It’s worth noting here that Rational Open Access, RPG Edition was the first major new piece of RPG technology out of IBM’s Toronto lab in years, but it is viewed by many as too little, too late.)

Today, it is tough to find anybody coming out of college with RPG skills. And why should they learn RPG when there is a much greater demand for people with skills in Java, C++/C#, and scripting languages like PHP, Python, and Ruby on Rails? Granted, the skills issue is just a part of the overall state of the IBM i platform, which has seen better days.

But the programming skills issue comes to the forefront when individual IBM i shops face the music and decide what they’re going to do with their aging IBM i systems. These systems have worked well for decades, but they don’t feature the intuitive Web and mobile front-ends that users demand today. The applications are often highly tuned to accomplish specific tasks in lightning speed. But when an organization wants to run new types of workloads or do new things with their data, they’re often challenged to figure out how to do that on the IBM i server.

As the stresses build up within an organization, the IBM i server often develops a “legacy” label. The breaking point often comes when senior RPG programmers retire and take with them critical knowledge of the business processes they encoded. In many cases, the applications are poorly documented, and the departure of the main steward of the business systems leaves a gaping hole in operational readiness. When IT executives see these holes and the large amount of operational risk they hold, they often panic, which leads to rash decision making.

Stuart Milligan of Databorough, a database modernization vendor, has seen this scenario play out time and again. “It’s fear of the unknown,” he says. “Executives are saying, where am I going? How big is my problem? How much code have I got and how dependent am I on which bits of code? You’re scared of what you don’t know.”

The problem may be solvable, but without a clear starting point, it can be tough to resist the urge to flee the platform. “These CIOs have the Sword of Damocles hanging over their head. They’re saying ‘These RPG programmers are getting older, it’s getting more difficult, and I don’t know how big my problem is.'” Milligan continues. “People get all hyped up about it and say, ‘Ah I’ve got to get off the platform. We’ve got to get somewhere.'”

That isn’t an easy argument for IBM i proponents to counter. Without well-documented business processes, the mess of RPG spaghetti code, the absence of original RPG programmers, and the IBM i platform’s undeserved reputation as an old, washed-up, has-been of a server can combine to doom the platform’s future.

“When the AS/400 people don’t have anything, forensically or scientifically, to show what it is they do, what they’ve got and its value, then they lose the battle,” Milligan says. “The AS/400 guys say, ‘It runs forever.’ But in that hyped-up technology atmosphere, where a young Java or Microsoft executive who has done big projects and is making a lot of noise and showing something that looks quite shiny and new, that’s got little effect on a board or an executive who has to make a long-term decision.”

It sounds obvious, but IBM i shops should never let the old FUD (fear, uncertainty, and doubt) factor influence their business decisions. The IBM i platform isn’t going away anytime soon. IBM still makes a tidy little profit on the back of the IBM i, and isn’t about to go all HP3000 on you.

With that said, you definitely should not ignore that RPG spaghetti code because it does in fact pose a threat to your business. Whether your organizations rolls its own RPG or runs a modified ERP package, the business rules coded in RPG represent the advances you’ve made in your business and the competitive advantage you have worked hard to attain over your competitors. Letting those RPG-coded business rules languish in the dark severely impacts your agility, and limits your future options regarding the program, which may include:

Modernize the application so that it runs more efficiently and affordably on the IBM i server
Migrate the application to run on another platform, or
Re-write the application from scratch

A couple of years ago, Databorough introduced a product called X-Audit that can automatically ferret out those RPG business rules and bring clarity to what the program does and how it does it. Whether or not a customer chooses ultimately to stay on the IBM i platform, the knowledge gained can have a calming effect upon decision makers. Call it a “V Spec” or Valium for RPG.

“What is interesting is, once people know that there’s a get-out strategy or there’s a strategy to evolve the application in a structured way and they’ve got visibility, then people lose the hype a little bit,” Milligan says. “Once you put it in front of them how difficult it is, how complex the task is, and how much code they got or they haven’t, then the whole thing just sort of slows down. Some still say, ‘Yeah let’s do it,’ and off they go. But others end up managing their resources more intelligently in RPG on the AS/400.”

If IBM i shops and ISVs are going to evolve their RPG applications to maintain relevancy over the next 40 years, they would do well to protect those all-important business rules, and a good way to start is by ensuring the documentation is up to snuff. There’s no reason to panic at this time, but a small investment now will make life easier down the road.