02
Sat, Nov
2 New Articles

RPG and DB2: The Future Is Now

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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):

Chain ITEM IIM;
WorkGL = IGLOVR;
If (WorkGL = *blanks);
  Chain IMCLAS IIC;
  WorkGL = ICGL;
Endif;
If (WorkGL = '*COMPANY');
  Chain CUST CUS;
  Chain CUCOMP COM;
  WorkGL = DFTGLACT;
Endif;


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..

Joe Pluta

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses 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. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i Developing Web 2.0 Applications with EGL for IBM i
Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform.
List Price $39.95

Now On Sale

WDSC: Step by Step WDSC: Step by Step
Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction.
List Price $74.95

Now On Sale

Eclipse: Step by Step Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: