There has been much discussion recently of the demise of RPG and native DB2 and even of the IBM midrange itself. RPG's detractors point to everything from the high number of Java programmers graduating from school to the infamous burger flipping ad to IBM's Developer Roadmap, which has been interpreted as a call to Java. SQL has been hyped as the next great tool for application developers, with its powerful data access capabilities and its perceived ease of use. And when questioned on things like performance and maintenance, the adherents of the Java/SQL strategy quickly fall back to the rallying cry of platform independence. Some go so far as to position the new i5 as the end of the storied IBM midrange line that included the S/38 and the AS/400. To them, the i5 is little more than just another database server in your server farm.

However, if you can get past the hype and view the situation with a little common sense, it becomes clear that Java and SQL (and its Java cousin, JDBC) are not the universal panaceas of programming. There are two reasons: performance and expertise. The two topics are somewhat related--the lack of business application expertise contributes to the performance problems--but each has its own additional quirks as well. And if you just take a look at the box, it's clear that the i5 is uniquely positioned in the industry with the most development tools ever assembled on one platform in history. If anything, software developers should be drooling to get their hands on this machine, rather than trying to relegate it to the trash heap!

In this first of two parts, I'm going to go through some of the many reasons that make RPG, with and without embedded SQL, a powerful tool that must be leveraged in the next generation of i5/OS applications. I'll also try to dispel some of the mystique that has recently grown around SQL--a mystique that has somehow created the notion that SQL is the best database tool for all programming problems. A similar aura seems to have attached itself to Java, to the point where people are actually claiming that Java performs better than RPG, and I'll address that here as well. In the second part, I'll review IBM's recent actions and report some what's being said inside IBM, statements that make it clear that the i5 is around for the long haul, not just as a database server on steroids.

The Emperor's Back, and He's Naked Again

What got me started on this entire kick is the fact that people I know and respect in the community are starting to say startling things--things that seem to fly in the face of common sense from my point of view. I thought we'd dispelled a lot of this a while back, but it's clear that a new round of uncorroborated statements is being bandied about.

The one that really got to me recently was reading in an online magazine that JDBC is as fast as RPG for Web serving. This is simply nonsense. There's no way this can be true, for any number of reasons. The justification given was "connection pooling," which somehow is supposed to mean that a Java program can get data off the disk faster than an RPG program can. I also hear people saying that SQL is just as fast as native I/O for everything and that IBM is putting all its money into SQL development and nothing into native I/O. There is a grain of truth to the second statement; IBM is certainly investing more in SQL performance than native, but that's because SQL needs it, and I'll talk about that more in the next column. As to performance, however, it's simply not true. Native I/O outperforms SQL by factors of two, five, or even more on basic I/O operations required by standard business programs. And Java just gets beaten to the dirt when it comes to decimal arithmetic.

Performance

There are all kinds of statements and claims being circulated in cyberspace these days about how Java and SQL have equaled or surpassed RPG in performance. To me, this defies common sense. Both SQL and Java require additional processing to do the same functions. The RPG runtime has been optimized over decades to provide the best possible performance, so it stands to reason that other technologies just haven't caught up yet.

For example, until very recently, SQL was a layer on top of native I/O. That is, in order to perform its functions, it needed to do some work and then invoke the same low-level I/O functions as the RPG runtime. Of course, RPG had to do the same, but its overhead was much less, since there was no parsing of parameters or any of the other things that go on in a typical SQL statement. Where SQL shines, though, is in multi-record processing. In RPG, you must come back "up" to the RPG program for every record, but with SQL, you spend all your processing time down in the low-level operating system routines. Thus, as the number of records processed goes up in a single SQL statement, the better that SQL performs in comparison to native I/O. And every benchmark I have done to date bears that out. For example, single-row SQL INSERTs take five to 10 times as long as a native WRITE. Single-row updates take two to four times as long. SQL doesn't come close to native unless you're doing sets of about 100 records. This makes sense; the more records you process at once, the better SQL performs. And this includes reading records as well.

Java has similar problems. JDBC is simply another layer on top of SQL, so common sense (a phrase I use over and over) dictates that JDBC would run more slowly. And indeed it does, by a wide margin. In a preliminary test, a single-row UPDATE statement took 13 times as long with JDBC as with embedded SQL. Another place where JDBC fares poorly is decimal arithmetic, specifically thee BigDecimal class. Mathematics using the BigDecimal class is about 10 times as slow as using packed decimal fields in RPG. Now, you might argue that the problem is the BigDecimal class and that arithmetic in binary is much faster, and you would be right. Binary arithmetic is lightning fast. However, at some point you need to convert that information to and from the database, and that operation takes even longer: nearly 40 times as long as the native operation itself. So, in two major areas of business applications--database access and decimal arithmetic--Java is significantly slower than RPG.

And don't take my word for it, either. Many of these benchmarks are already available at the iSeries Application Architecture Initiative (IAAI). We're adding new benchmarks constantly, but many of the basic benchmarks are available now.

Programming Productivity

I find it interesting when people tell me SQL is easier to read than RPG. I suppose that if you've never seen RPG and you're proficient in SQL, that would definitely be the case. But I'm pretty proficient in most programming languages, and I find SQL to often be dense and impenetrable, especially once someone starts "tweaking" the statements for performance. On the midrange.com mailing lists, I presented a simple situation, and I'm going to make it even simpler for this article.

Suppose you want to find the general ledger account number during order entry. Normally, you find it in the item class file (IIC). Each item has a class, so you get the item master (IIM) record and use that to chain to the item class. You can have an override value in the item master. Also, either the item master or the item class can have a special value called *COMPANY, which uses the default for the company, which is in the company master, which you access via the customer record (CUS) and then the company (COM).

I realize this isn't a single-record fetch. But it's really easy to do in native I/O. Start with item number (ITEM) and customer (CUST):

I find this code pretty readable, even without comments. I tried to figure out the SQL equivalent, but I got stuck where I had to JOIN in four files; it was clear that code would perform quite poorly when those records were not needed. Also, the only way I can see to program the IF statements is by using CASE constructs, and those typically make my head swim.

Platform Independence

This is the issue that really irks me. Platform independence makes sense for three groups of people: ISVs that want to sell their product on whatever machine you have, hardware vendors that want you to buy more hardware to offset the performance hit you take by switching to non-native solutions, and consultants who simply want to rewrite everything you have, regardless of the fact that it's working just fine.

I am going to be blunt here: If you understand the concept of a tiered architecture, where you can isolate your user interface from your business logic, and you still think you want to move your business logic off of the iSeries, then you just aren't listening to the facts. Everything from meantime between failures to total cost of ownership to performance shows that the iSeries is the best business logic platform on the planet and that RPG is the best business logic language. Add in iSeries security and the fact that it is the most open platform ever designed, and it seems inconceivable to think that a move to any other platform makes any kind of business sense. Sure, your user interface needs to grow and access to your data needs to be flexible, but dumping the iSeries in order to get a nice GUI is very much throwing out the baby with the bathwater. I've successfully implemented n-tier architectures in which browser response times rival green-screen response times, and nearly all the code is in RPG, but the user interface is as flexible and user-friendly as anything you'll see.

Programmers

This is usually the final argument. The way it goes is this: Colleges aren't turning out RPG programmers, so our old RPG code is going to be obsolete. All the new programmers are now Java experts, and that's where we need to move. While this may sound good in theory, a couple of real-world obstacles could prove fatal to any attempt at wholesale migration.

First, your current programming skill base is likely heavily weighted toward RPG. This means not only that your programmers know RPG, but also that your business rules are written in RPG. Moving to any other language entails a complete rewrite of those business rules, and all those rules are in the heads of your RPG programmers. It's quite unlikely that a newbie out of college has any business application experience, much less can understand your business. And that means you'll have to train all those newbies. Or more to the point, your RPG programmers will have to train those newbies. If your company position is "RPG is obsolete, Java is the bee's knees," then you're running a high risk of alienating the people you need the most.

Instead, you should be focusing on a strategy in which you gradually move to Java, if that's where you want to go. Encapsulate your business rules in servers and expose them as services to your UI tier. Note that this can be JSP/servlets or .NET or Web Services or whatever you need. My guess is that by the time you've put those interfaces in place, you'll find that your most productive environment involves both RPG and the newer technologies. And if not, you now at least have small, encapsulated servers that you can then proceed to rewrite without affecting your production systems.

So What's the Verdict?

Java and SQL are powerful adjuncts to our base programming skills. Rather than rewriting existing logic into these new programming languages, you should instead be looking for ways to make the old and the new work together. The Java/SQL/.NET developers should be focusing on whiz-bang queries and powerful user interfaces, not rewriting item master maintenance.

But this relates to a problem I see growing in our community: There are some really distinct classes of business problems that need to be addressed, and the tool that best suits one does not necessarily suit another. The primary advocates of SQL and JDBC are folks who write lots of queries. And I'll be the first to admit that SQL is a dream tool, especially for ad hoc queries where the user dynamically chooses sort, filter, and summary requirements. But that's only a small portion of the world of business applications. When you start looking at the online transaction processing applications like order entry, it's clear that the approach to database access becomes quite different. Single-record access becomes the norm, and our benchmarks clearly indicate that RPG solidly outperforms SQL across the board for single-record access.

The right answer is an application architecture that supports the commingling of these technologies. Together with the new open features of i5/OS and the eServer platform, I think we're on the verge of a whole new era of user productivity. But that will never happen if we squander the next several years rewriting our current systems to meet some abstract goals that don't even make business sense.
The tool we need most to use these days is common sense.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step, with WDSC: Step by Step coming soon. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..