Now You Can Transform RPG Code Into PHP
September 21, 2020 Timothy Prickett Morgan
Assuming an average of 5 million lines of code at IBM i shops – a number I heard recently thrown around – in their homegrown or heavily customized third party applications, IBM i shops are collectively sitting on something like 750 billion lines of code. Just ponder that for a minute.
This code, which is predominantly written in RPG but with a fair proportion of Java and COBOL plus a smattering of more modern languages, is going to have to be maintained and tweaked in the coming years. Just like it had to be updated and debugged time and again as business changed over the past several decades. The expectation is that programming skills in RPG and other heritage languages like COBOL will become progressively in shorter and shorter supply as programmers retire, and this will be at the same time as demand will be rising to undergo modernization efforts.
Something has got to give.
And that something is very likely not going to be that companies just sign big checks over to Oracle or SAP or Infor or some other third-party application provider and completely rework the way their companies work. That is just not plausible in a lot of cases, given that applications encode the very practices that make companies unique. And as much as a company like Oracle or SAP or Infor will try to tell you that their applications embody the very best and most modern business practices, they also make a fortune doing customizations for end user companies. So maybe they have a vested interest in leading you down the garden path. And not just the first time, but every time they update their code, they have to update your modifications.
The holy grail, of course, is to automate the whole process, to transmute an application running in one high level language into another more popular and more modern language. We have seen a bit of this over the years, with a certain amount of success, particularly in the past decade ago with tools that converted RPG to Java. But Java is not everybody’s cup of tea these days, and there are a lot of programmers who want to use something a little less heavy but also modern and popular so the pool of skilled programmers has a lot of swimmers splashing around instead of a few geezers doing laps.
This is why Fresche Solutions, which has a heritage in tools that convert RPG and Synon 2E applications to Java has updated its X-Modernize toolbox to now include features that allow it to convert RPG to PHP. And with the combination of Fresche’s X-Analysis, which can assess the current state of the RPG application portfolio at a company before any conversion to either Java or PHP, the scope of that conversion process can be made smaller and somewhat easier.
“If you look at, say, 5 million lines of RPG code, it’s probably more like 3.5 million that needs to be converted,” Marcel Sarrasin, chief product officer at Fresche, tells The Four Hundred. “The beauty of X-Analysis is that it tells you how much or how little the source code has been touched in the last few years and how much code is not necessary at all. For one company that we are working with today, the issue was reducing how much money it cost them internally to maintain code and do transactions. Let’s say it’s 30 cents a transaction. But with the new approach, which is a combination of code analysis and code transformation, they are going to get that cost down to 10 cents a transaction. That’s a long-term value, to be sure, but this is also about the risk. What is the risk of not being able to hire RPG programmers?”
The risk is, in one way, pretty unclear and also pretty uncertain. It is safe to say that demand is going to chase supply, unless automation of code transformation and the use of modern languages like PHP are at the other end of that transformation.
No code transformation is perfect, of course, moving from one language to another and when it encapsulates the programming styles of different programmers using different generations of RPG over many different versions and releases of the application over many decades. The rule of thumb is that about 85 percent of the code in a typical RPG application can make the jump, and the remaining 15 percent of the code that runs through the transformation engine has to be tweaked or fixed by hand in PHP. So, in our theoretical example, we started with 5 million lines of code, and then 3 million lines of code are actually put through the conversion process to PHP without having any changes and maybe 500,000 lines of code have to be fixed when the PHP comes out of the other side. That’s only 10 percent of the original code that has to be touched, and this significantly reduces the cost of doing a conversion of RPG to other languages.
None of this is simple, painless, or free, and the experts at Fresche would be the first to tell you this. But they are making it quicker, easier, and less costly than it might otherwise be, and that is important. Some might say vital to the business in an era when things are changing fast and agility and cost are top of mind among the CEO and CFO and therefore the CIO.
“The cost of this full conversion process, including code transformation, is usually less than 50 percent of the cost of hand writing an application,” explains Robert Rheault, chief operating officer at Fresche. “And, you de-risk it and reduce the timeline. When you rewrite an application by hand, you just keep going and going and then you realize after a year and a half, it is only 10 percent done. It is easy to miss logic when you do it manually, too, so the risk is very, very high. So, we reduce the risk a lot on these types of projects by converting the business logic – everything is going to be there. Sometimes we do a big cleanup after – remember, the old adage of garbage in, garbage out still holds – and at the end of the conversion process, we have a more modern codebase that we can play with.”
The other factor to consider is that buying an ERP package from a third party vendor is not really going to necessarily be faster or cheaper than a code conversion project that includes a mix of transforming using tools and hand coding using experts. Rheault says that for typical IBM i shops, which have been in business for many, many decades and have encoded the essence of their businesses into homegrown or customized code over decades, and off-the-shelf ERP or CRM or SCM suite might cover 50 percent or 60 percent of the functionality required, and have a whole lot of unnecessary stuff that customers have to pay for. And what is missing must be added in as a customization to those packages. This takes both money and time, and we all know that time is money, so what we are really talking about here is money.
One of the keys to doing a big conversion from RPG to PHP – or RPG to Java, for that matter – is to take it in steps, and to have to costs also come in phases.
“The other big thing we offer to customers is being able to produce slices of the application using an agile approach,” explains Sarrasin. “One of the projects we have now is a five-year modernization of a massive application, but we’re going to have deliverables – real deliverables – within about nine months. People are going to be able to use the new code over time, and the transformation and conversion is priced that way as well. They don’t have to pay for that five-year project all at once or in two pieces – we do pay as you go and have flexible options to work with CapEx and OpEx alike.”
“People often ask me what it really takes to make transformation or modernization successful” adds Rheault. “Our team is pretty significant. We don’t have four guys that are the same four guys we send on every project. We have experts in almost every vertical and every type of software out there that runs on IBM i. Most importantly, for over a decade our people have been doing transformations so they know what can and will come up in a project – and how to overcome it. Everything from planning, alignment with the business, integration, testing, deployment and managing change. And, it takes a team effort – client and us. So, a very unique offering compared to other businesses that say they do transformation.”
Sarrasin adds: “You can’t really underestimate the size of the team or skills you are going to need or even the types of services required. When you are talking projects that are a year, two years, sometimes more, the level of expertise needed can and often does vary – even throughout the project.”
Now here is the clever bit of the new and improved third generation of the X-Modernize code converter that caught our attention. The RPG parser now populates a meta layer, and this is what lets Fresche to set itself and its customers for the future. The meta layer can pull in RPG code – columnar RPG or free form RPG, both are supported – and this meta layer analyzes the code and converts it to an intermediate form that can then be used to pump out Java or PHP – or any other language customers might want, such as Node.js or C# or whatever there is enough demand for to justify the engineering to change the output in the other side of the X-Modernize tool. And when we asked if the input language could be something other than RPG or Synon 2E, Sarrasin said in theory this could change, too, depending on market demand but the underlying technology could do it.
There are all kinds of language translation and therefore application conversions that might be possible in the future from Fresche. The possibilities are. . . intriguing. PHP or Java code converted from RPG today could be the input to X-Modernize a decade or two from now to heaven only knows what output language. With our luck, it will be assembler because Moore’s Law stopped dead.