Newsletters Subscriptions Media Kit About Us Contact Search Home

OS/400 Edition
Volume 12, Number 17 -- April 28, 2003

The Future of Programming on the iSeries, Part 2

by Alex Woodie and Timothy Prickett Morgan

When was the last time you saw a new RPG application? Not a productivity tool for programmers or a utility for system administrators, but an honest to goodness application, the kind that office workers and factory employees across the country use to keep their business running on a daily basis. While you may be able to come up with one or two for the last year, just about everybody Guild Companies contacted for this story on the future of programming on the iSeries agreed that RPG development on the OS/400 platform is past its prime and is entering that slow downward spiral toward the place where all computers, programmers, and programming languages eventually end up: the big binary pasture in the sky.

It's not that RPG is dying because it's a bad language. It is very good at what it does, which, today, means embodying the business logic that accesses the DB2/400 database and making it do transaction processing, generate reports, and manage the data processing that runs businesses of all kinds.

RPG could have been the Java of its time, or certainly could have been within the midrange sector of the server market. As the AS/400 started to take off in the late 1980s, there were RPG compilers for all sorts of platforms, including mainframes, minicomputers from DEC and Wang, and Hewlett-Packard HP3000. IBM also had RPG compilers for its mainframes, and eventually had clone compilers, from a third party, that ran on its PC servers. But these non-IBM RPG compilers were not exactly compatible and were seldom used. Quite frankly, IBM didn't conceive of trying to make RPG an open standard, much as had been done with COBOL, Fortran, and SQL. There was precedence for this, but no prescience. This undoubtedly hurt RPG's uptake and longevity, compared with other procedural languages, such as COBOL, for which there are hundreds of different versions and compilers, and which is supported by many independent vendors. Compared with RPG, COBOL--an equally ancient "card-whalloper" compiler, with a history reaching back into the punch-card era--has good legs, and for good reason. The consequences are that very few RPG applications were ever written on non-IBM platforms--nor, indeed, on any other platform besides the System/36, the System/38, the AS/400, and the iSeries.

Market researcher Gartner monitors the health and outlook of RPG, as it does for all major programming languages. Jim Duggan, a vice president who covers application development issues for Gartner, says that, in RPG's case, all of the different indicators Gartner uses to gauge the viability of a language--including frequency of releases, availability of training, availability of trained staff, use in new projects, application population, programming constructs, tool support, and hardware support--are pointing in the wrong direction.

Duggan recently downgraded RPG from the "mature" category to the "aging" category. This means that the frequency of releases for RPG has moved from "irregular" to "seldom," and that the availability of training has gone from "dropping" to "low." Spot shortages are beginning to appear in the availability of trained staff, and RPG is "seldom" used in new projects, according to Gartner. The application population moves from "stable" to "dropping," but programming constructs remain stable. The availability of tool support goes from "dropping" to "incomplete" in the aging category, and hardware support goes from "complete/delayed" to "defined/incomplete." It usually takes five more years for languages to move up or down a peg. In RPG's case, Gartner will eventually move it to the "elderly" category, which is the last stop before that big binary pasture in the sky. Java, by comparison, along with C++, is enjoying the peak of its powers as an "adult" language, with an expected station there of more than 10 years.

In some parts of the United States, there is a surplus of RPG programmers, compared with the open positions, and there's tough competition for jobs. But that's not the case everywhere, Duggan says. "What we're seeing is spot shortages," he says. "Not in the Upper Midwest, where there are more RPG programmers than you can shake a stick at. Far from there, the numbers [of trained RPG programmers] are plunging." As the spot shortages become more widespread, there will be more occasions for one company to raid another for RPG skills, and it will become harder for companies to recoup their iSeries hardware investments because of the higher cost of good RPG programmers, and even operators who write CL programs, Duggan says. Organizations that can't compete for these scarce programming skills because of rigid pay structures, like public universities, will find it very difficult to retain qualified programmers, which will provide a certain degree of motivation for migrating off the platform.

So What Is an OS/400 Shop to Do?

While the OS/400 platform and RPG share very close bonds, it's important to note that the success of one and the demise of the other are not necessarily intrinsically tied, Duggan says. "I've got to say, IBM gets a bit of a bad rap from the community, in that they aren't actively trying to sabotage the platform, but the community wants them to stand up and defend RPG vigorously. It just doesn't make good business sense," Duggan says. "The RPG issue has taken a life of its own. The OS/400 platform will long outlive RPG."

As RPG slowly dies, Duggan recommends several alternatives for writing programs on the OS/400 platform. "Java is the easy answer, but it falls short of what language exploits this machine well," he says. "Java is opposed to the design philosophy of the AS/400." To build a buffer against the impending shortage of RPG skills, while retaining some of the architectural advantages of RPG, Duggan recommends customers take a look at some of the fourth-generation-language (4GL) programming environments that can generate native RPG, including LANSA and Computer Associates Advantage 2E and Advantage Plex (formerly Cool:Plex and Cool:2E). (Duggan was particularly keen on the potential of Advantage Plex. "When CA acquired it, it had tremendous potential," he says. "Cool:Plex, as recently as three to four years ago, was one of the most advanced tools available. It was the first to do patterns, but it insisted on making up new names, so it looked more proprietary than it really was.")

There are many options available for companies that want to maintain their RPG code to handle the logic and access the database, but want to build new GUIs to replace the green-screen 5250 interfaces. In addition to Java development tools, such as those available from IBM in the WebSphere Development Studio (which provides a mix of RPG and Java tools), there are a number of interface extension products that will assist developers in writing new XML or HTML interfaces. Software vendors in this category include ASNA, BCD Int'l, ClientSoft, Jacada, looksoftware, NetManage, Profound Logic, ResQNet, SEAGULL, WRQ, and many others. Companies may also choose to write new interfaces to RPG programs using Microsoft Visual Studio .NET and C# tools, or to develop in any number of other environments, such as Curl, Perl, JavaScript, or even good old RPG-based CGI. IBM's new WebFacing tools are another example of these legacy application extenders. This is by no means an exhaustive list. There are lots of companies in this area.

But these are tools are predominantly aimed at building new interfaces to old applications, not writing new logic or building new applications for the iSeries. As a source of new applications for the iSeries, nothing yet has surpassed the potential of Java.

Making the Jump from RPG to Java

For iSeries shops that have made the commitment to Java, there is seldom a good case for moving or rewriting all of an application's function from RPG into Java. As we pointed out in last week's story, this is precisely what IBM warns customers not to try to do. Java's main role on the iSeries is in bridging the gap between host-based computing, like the RPG-DB2/400 applications developed over the past two decades, and Web-based computing.

Plenty of independent software vendors that have created RPG applications agree. "The application is king," says Malcolm Rose, development director at Geac, which recently release a new version of its RPG-based ERP system, System21. "Our customers are happy to be running their applications on an iSeries, and there's little benefit to converting those applications."

Geac recently converted System21 to RPG IV, which is more Java-like and integrates better with Java than earlier versions of RPG. This move to RPG ILE is bolstering its extension strategy, in which most new customer-facing applications will be developed in Java. "We've had some pretty good success, converting good RPG programmers into Java programmers," Rose says. To date, the company, which does most of its development work from its headquarters in England, has converted about half of its RPG programmers, or 30 to 40 of them, into Java programmers. "The most valuable technicalists easily switch between RPG and Java," adds Stephen Rees, a development manager with Geac.

While independent software vendors may have coders who can make the jump quite easily, this is not generally the case among OS/400 shops. They have a limited number of programmers trying to keep up with user requests and maintenance on their RPG applications, and they have little time or money to hit the pause button to let everyone go and learn Java for future projects. "The thing that I am hearing from managers, who are as frustrated as programmers, is the resistance to change," says Nate Viall, the principal of Nate Viall & Associates, a company that has been specializing in job-placement and compensation issues in the midrange for two decades.

Viall says the problem is complex. First, the managers that he has spoken with are a bit surprised that programmers with deep RPG skills have had trouble making the jump to Java and other programming languages. While this is not universally true, it is pervasive, and if it is true for Java, it will be true for .NET. Viall offers an apt metaphor to explain it. Moving from RPG to Java is not like knowing Spanish and then learning a closely related romance language, like Portuguese; it's like moving from Spanish to Chinese, which has not only has a different alphabet but also a different culture, making learning the new language all the more difficult.

The second problem that Viall hears about are companies that give programmers a chance to learn Java, and they experiment a little, but at the first opportunity or excuse, they are back in RPG, handling user requests, instead of coding in Java. Many programmers apparently prefer day-to-day maintenance in RPG, where they are experts, to struggling to make a simple program work in what amounts to an alien language, Java. The fact is, just about everyone is incompetent while learning a new skill, and management that doesn't account for this perfectly natural human nature is bound to be disappointed, just like RPG programmers trying to learn Java will be at first.

So what does Viall think programmers in OS/400 shops should be doing? "The short answer is that they need flexibility; they need to try new things and experiment. OS/400 shops are victims of their own success. They've done things well for a long time, and change is going to be difficult." But he doesn't necessarily think Java is the easy answer, either. "Is Java going to be the solution five years from now? I don't think anyone can predict that. Microsoft is certainly going to argue that .NET is the answer."

There's one other thing that programmers have to consider as they plot their future. In the end, it all comes back to the application. The business processes embodied in all that program logic are just as important as the program logic. This knowledge is what makes a good programmer a great asset for any company, not just the one a programmer is currently employed by. A good understanding of APIs is also key.

The most important thing for a developer to have is a good understanding of the application, says Gary Drake, a development manager with ERP vendor Intentia International, which rewrote its RPG-based application, Movex, in Java. "Someone who has an understanding of the Movex standard will find it easy to understand the Java version as well," Drake says. "We've kept the architecture consistent, so it was very easy for an RPG developer to become a Java developer" at Intentia. The same would hold for a user, Drake says, because the Java version of Movex makes greater use of APIs to modify an application or a business process. In the RPG world, the programmer would have modified the RPG source code directly; whereas, in Intentia's Java world, they'll use a tool to access that API.

For years, IBM has been pushing OS/400 shops and developers to move up to RPG IV, which has more of an affinity with Java than RPG III and can be seen as a stepping stone to increased Java functionality with RPG programs. No matter how modular RPG IV is compared with RPG III, however, RPG is still a procedural language, and developers accustomed to doing things the RPG way will find it difficult and expensive to make the switch to an object-oriented language, such as Java, says Gartner's Duggan. "That's a pretty major job for somebody on the AS/400, to go from procedural to object-oriented," he says. A good RPG programmer may want to learn Java to enrich his set of skills. "But from a corporate perspective, it's not doing the right thing for the business to go down that path."

As you can see, not everyone agrees about what OS/400 programmers should be doing or in which direction managers should be coaxing them. There is no magic answer, and that is life. The point is to act. A moving target is always harder to hit than a sitting duck. The more you know, the more useful you are.

Breaking Out of Plugger Mode: Attitude Is Key

Duggan says that many OS/400 shops are satisfied with the status quo, insofar as they are not planning beyond RPG III. "I think most of them are in plugger mode," he says, and they will be the first to pay--and pay dearly, they will--when IBM ceases to support RPG III. "It won't do, just to hang on. They have to plan for the evolution. They need to make their shop so efficient that it doesn't pay to go" to anther platform, Duggan says. "On the other hand, the most progressive OS/400 shops," he says, "are the ones who say yes when a manager asks, 'Can you do this?' "

Roger Pence, an RPG expert and education director at RPG and .NET tools vendor ASNA, says the blame belongs not only on the OS/400 community but also on IBM, for a lack of leadership in developing languages. "The problem is not the box; it's the community," he says. "Who's investing in the new programmer community? That's what IBM needs to see, and that's what it hasn't done."

IBM has had a knee-jerk reaction to the issue of new programming languages for the AS/400 platform, Pence says. "Had IBM a long time ago stuck with SmallTalk, and done something right by SmallTalk, maybe we would have been somewhere else. It didn't stick with anything long enough, and that's where we are with Java right now," he says. "The AS/400 community hasn't been appropriately motivated to do other stuff. IBM is at fault for that."

To read the first article in this series on the future of RPG programming on the iSeries, click here.

Sponsored By

Making 'Order Out of Chaos'
What will IBM's iSeries and WebSphere announcements
mean to your business?

TamGroup is one of IBM's largest Business Partners specializing in iSeries, WebSphere and multiplatform environments. Spend one hour with us to learn the 'real story' about IBM's announcements. We will discuss how to take advantage of special promotions that end in January, saving you tens-of-thousands of dollars. We will help you determine what your next move should be with your iSeries systems.

Visit our website to learn more about our weekly web seminars covering:

  • WebSphere Portal 101
  • WebSphere Portal 201
  • B2B Integration
  • Content Management
  • Security and Managed Availability


About TamGroup
TamGroup is a leading provider of information solutions that leverage and extend our customer's existing information assets with emerging business technologies. We specialize in the integration, management, and delivery of information, so our customers get the right information to the right people at the right time. As one of IBM's Top Premier Business Partners, our consultative solution approach empowers our customers to create a competitive advantage while lowering IT costs.

Founded in 1995, TamGroup provides customers collaborative business integration software; builds portal and content management solutions; and implements secure, highly available server and storage infrastructures for medium to large enterprises. TamGroup is the developer of Nexuse2e™, the industry standard business-to-business integration software selected by the Agriculture and other industry groups. TamGroup customers include Bayer, Cox Communications, DuPont, Discovery Channel, Monsanto, and many others.

TamGroup, an IBM Premier Business Partner


Aldon Computer Group
Quadrant Software
Brooks Internet Software


The Future of Programming on the iSeries, Part 2

IBM Revives iSeries Rebates to Drive Sales

IBM Invests in ISVs; Modernized Apps the Key

Admin Alert: Staying Current with iSeries Access and Lotus Domino

Shaking IT Up: What a Wonderful IT World

But Wait, There's More

Timothy Prickett Morgan

Managing Editor
Shannon Pastore

Contributing Editors:
Dan Burger
Joe Hertvik
Kevin Vandever
Shannon O'Donnell
Victor Rozek
Hesh Wiener
Alex Woodie

Publisher and
Advertising Director:

Jenny Thomas

Advertising Sales Representative
Kim Reed

Contact the Editors
Do you have a gripe, inside dope or an opinion?
Email the editors:

Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.