"The news of my death has been greatly exaggerated."
--Samuel Clemens

If RPG were a person, it would have a lot of sympathy for Sam Clemens these days. RPG has been a dead language for decades, it seems. It's even been given that most horrible of epitaphs: "legacy." "Legacy" programming languages are kind of like "classic" rock: stuff old people listen to and certainly not hip enough for the new generation. But you know something? I personally think classic rock stands the test of time. From Aerosmith to Zeppelin, classic rock will probably be listened to long after 99% of the current batch of manufactured boy bands and wannabe gangsta rappers are forgotten history. Quality workmanship by people who were in it for the love of the business will always outshine glitzy eye candy produced strictly for profit. Think of RPG as the Rolling Stones or the Beatles or the Beach Boys--good, fundamental work year in and year out for decades. Then think of .Net as 'NSync or the Spice Girls: pretty, fluffy, and without substance; easy to use, easy to forget; a guilty pleasure that you will look back on a few years from now and wonder what you saw in it.

In this column, I'll tell you why RPG is the once and future business language and how IBM is proving it every day. I'll show you what WDSC brings to the table for RPG programmers, and I'll tell you about the most important additions to the language, as told by the people who actually write the compilers!

RPG: Built for Business

RPG is built for business. Common sense tells us that a good, solid language with fast, simple database access integrated into the runtime will perform better than a one-size-fits-all interface built by a committee. But common sense doesn't stop IT from embracing the latest fad. Today, if it ain't new, it ain't good. And that doesn't even apply, because as we'll see later in the article, much of RPG is quite new; RPG is evolving as fast as or faster than any language out there, and the bulk of that effort has been focused on allowing us to build powerful business engines instead of wasting time in the endless UI wars (does anybody remember Struts?). And yet even in our own community (in fact, in our very own MC Press forums), some vocal naysayers insist that RPG is dead. They use all kinds of arguments, such as the number of jobs on Dice.com or the fact that colleges aren't teaching RPG. They do this while conveniently forgetting that historically RPG programmers didn't get their jobs by going to a headhunter after getting a computer science degree; typically, they got their training on the job, often moving from production roles to IT.

The big myth is that there will be no new RPG programmers. This is just silly. Why? Because the number of lines of RPG aren't being reduced in any great number. Some are getting replaced, but remember that there are billions of lines of RPG code out there, and they're not being replaced anywhere near as fast as the self-proclaimed experts said they would be. Remember back in the late '90s when all we heard was that vast numbers of companies were tossing out their IBM midranges and migrating from RPG to Java or some other architecture? Isn't it odd that we haven't heard a corresponding number of success stories? You'd think that companies (or at least their migration vendors) would talk up the great success and terrific cost-savings of these ventures, and yet we're not hearing such stories. In fact, I don't remember the last successful conversion I heard of. And that's because RPG is simply the best language for business logic, and that's why RPG will continue to be around for many, many years to come.

So you do the math. If the number of RPG programs isn't going down that much and the number of programmers is, then the supply and demand model starts to kick in. As the number of RPG programmers begins to dip, the premium on their services will go up. Demand will outstrip supply, and RPG programmers will begin to find themselves moving toward the high end of the scale. And when that happens, all the mercenary programmers who hopped on the .Net or Java bandwagons will all start looking at RPG as the next new phenomenon. And unlike the rather steep learning curve required to learn Java, RPG is a very easy language to pick up--and /free makes it even easier for those with a background in the C syntax. I predict that sometime in the next five years, the number of Java programmers learning RPG will surpass the number of RPG programmers learning Java.

You might argue that rising RPG labor costs will push IT managers to dump their RPG systems in favor of prepackaged Wintel server-farm solutions. A few years ago, I might have been worried about that, but the fact that IBM is actively fighting the server farm model (I love the commercial with the guy who says the servers are there to serve them) gives me hope. It's been clear for several years now that server farms are a poor architecture for most business applications. They're great for things like user interface front-ends and massively parallel processing such as weather forecasting, but they fail miserably for business applications in which the database is the most important thing. But even so, it's hard for an IT manager to stand firm against the onslaught of Microsoft misinformation; today's corporate society isn't geared for the guy pointing out that the emperor is naked; thus, the move to server farms was often undertaken despite clear but unsexy evidence against it.

But with IBM advertising for server consolidation, server farms are no longer the media darling. In fact, they've lost considerable luster as total cost of ownership and ease of management start to get more importance than initial costs, and with the recent price reductions, even the initial price point issue is softened. All of this combines to once again position the iSeries as a premier solution, making it that much harder to justify dumping something that works for something that is no longer a sure bet. In fact, I see server farms as having already peaked, because custom software doesn't work very well with the server farm model. So server farms really only make sense with pre-packaged software. However, if you look at it from a realistic cost/benefit standpoint, the Application Service Provider (ASP) model (or what we used to call "service bureaus" back in prehistoric times) will often be a better fit for those companies that can run on pre-configured software. Even in those shops that use them, server farms will be relegated to user interface servers and EIS queries, with RPG providing the back-end processing. Once you get past the smoke and mirrors, server farms have a relatively small niche that's getting smaller every day.

WDSC Proves the Point

Meanwhile, IBM has been pouring money into the iSeries and its flagship language, RPG. In my previous "Weaving WebSphere" column, I stated: "Unfortunately, I haven't found anything in WDSC6 for RPG programmers." And while that's strictly true, you must take it in context, along with the subsequent statement: "As it turns out, I think perhaps the 5.1.2 release was something of a shakeout for the new features. These features were then wrapped in Eclipse 3.0 and released as WDSC6."

I still contend that this is the case, and I think it makes sense to take a closer look at just what some of those features are. Back in June, I noted several features, including the outline, the code assist feature, the fixed-format prompting, and the built-in conversion from fixed- to free-format.

Wizards

These are only a few of the features that WDSC provides. One set of goodies I left out of my last column were the wizards. Currently, three wizards exist for generating source: the procedure wizard, the D-spec wizard, and the Java method call wizard. With varying degrees of user-friendliness, these wizards can remove a lot of the drudge work involved with performing certain mundane tasks.

The procedure wizard allows you to specify the parameters of a procedure and then automatically generates both the prototype and the procedure definition in your code. Figures 1A and 1B show a typical use of the wizard: creating a procedure with three parameters. Each parameter is added using a second wizard panel. It's not perfect; you can't use LIKE to define parameters, which really bugs me. And once you've got a catalog of code to work from and you've developed your own style, simply cutting and pasting your own existing code will probably be faster than using the wizard. But especially when you're just getting acquainted to RPG IV, it's really a great way to make sure you get your syntax correct. I only wish I'd had this when I was learning procedures and prototypes.

Figure 1A: The procedure wizard allows you to define a procedure. (Click images to enlarge.)

Figure 1B: This is the code that was generated by the wizard in Figure 1.

And there are other wizards. The D-spec wizard is deceptively simple. With it, you can create a D-specification with all the proper keywords in a standard way. But hidden under the covers is the ability to create an entire program status data structure with just a few keystrokes. Sure, it creates fields I don't need, but it's no problem to go in and delete them. You can use a similar wizard to create file information data structures. I'll never again have to remember (or look up) the fact that the AID byte is in position 369 of the information data structure.

The Java method call wizard is a prime example of a wizard that you might use for prototyping but that you should probably avoid for actual production code, at least in this version. The wizard does a lot of work, and not all of it is either necessary or even always correct. For example, it builds a constructor for the class whose method you are calling. However, it builds only the default constructor with no parameters. It's just as likely that you might use a constructor with one or more parameters, so this default is a little constricting. Also, the wizard generates the code that calls the method but nothing that calls the constructor. Finally, if you add another call to another method in the same class, things such as the constructor definition are duplicated.

The wizards are quite powerful, but they still have a way to go. For example, one thing I don't like is that the wizards are "output only"; you use them to generate a data structure or a field, but you can't then reuse the wizard to modify that definition. I write code generators for a living, so I recognize that such round-trip management is really difficult, but it sure would be nice.

Verify

The program verifier is another really powerful feature of the WDSC tool. Even though it's been around since the first days of WDSC, many people still don't know about it. The verify option allows you to basically perform a compile without going to the host. It doesn't create an object, either, so in effect it works like a CRTxxx OPTION(*NOGEN), except that it is much faster. And if you do have errors, you can then have them inserted into your source code at the appropriate locations so that you can see the error in context. It's a powerful way to find and fix syntax errors.

Figure 2: Errors from the verifier can be embedded in your source code for context.

Other Features

I can go on. If I had enough space, I'd go into detail about the many other features, large and small, in WDSC. These include things like the ability to copy a rectangular block of text; this is crucial in ILE RPG programs where you are moving many fields from one structure to another. By using qualified names, you can do some very clever things with field names. The rectangular copy allows you to get around the fact that RPG doesn't currently have a move-corresponding type of opcode. Another very interesting feature is the concept of a code template. Templates have been defined for your RPG code (/free only, unfortunately) that allow you to quickly invoke set patterns of coding. But the really cool part of this is that you can write your own templates. I haven't done much of this yet, but I get the idea that it could be a real timesaver on certain things (like, say, initializing a subfile). With the coming integration of SQL and /free I think we might see SQL templates as well.

I could go on and on. I just want you to realize exactly how much development time IBM is pouring into the RPG tooling of WDSC. There are features in the RPG LPEX editor that don't even exist yet in the Java editor; that's pretty impressive, considering how integral Java is to the Eclipse/WDSC product line. When I said there was nothing new in WDSC6, that didn't mean that there's nothing in WDSC for RPG programmers. On the contrary, WDSC is fast becoming the tool of choice for RPG development, and I expect to see more features in the future.

But It's Not Just the Tools

You still might not be convinced. You might be skeptical of the whole WDSC thing, seeing it as yet another plot to derail the purity of the iSeries (or do you still say AS/400?) development experience. Just another fat, bloated PC product that requires a $2000 PC just to run--it's not lost on you that WDSC runs only on Windows. What's up with that? Isn't IBM all about Linux?

So let's leave WDSC out of the equation for now. At this point, the Java devotees in particular start in on the fact that RPG is old and tired. It's a "legacy" language and is entirely procedural (that last word often said with the same disdain one might use for the word "booger"). They say Java is evolving so quickly and RPG is fossilized. However, upon further review, we find that just isn't the case.

For example, up until the Tiger release, there hadn't been any serious syntactical changes to the Java language since it's inception. Instead, the vast majority of changes are either basic programming constructs like lists or some basic infrastructure stuff like security. Huge changes have been made over the years in the user interface portions of Java, all of which are all but meaningless to the primary use of Java in iSeries shops, which is Web development.

On the other hand, I managed to get some insights into the many changes in the RPG language over recent years from some of the folks who actually do the development on the RPG compiler. Barbara Morris and Gina Whitney revealed to me how the folks who actually bring you the RPG compiler feel about their baby.

SQL Precompiler

This is Gina's particular area of expertise, and I thought I'd bring it up first because the poor precompiler is oft-maligned but rarely praised. That's probably because it's like the electric company: We only notice it when it doesn't work. The vast majority of us simply flip the type to SQLRPGLE, add a couple of /EXEC SQL statements, and away we go. It's not until something falls over that we even notice the precompiler, and the fact is that a whole lot of magic goes on under the covers, and more is being added every day. Here are just some of the recent features:

One of the problems with the various SQL compile commands was keeping up with all the parameters that were added to the corresponding non-SQL compile command. Adding those to the myriad of SQL options (things like ANSI compliance or commitment control level), the number of parameters was becoming pretty unwieldy. The way around it was to provide a parameter COMPILEOPT, which allows you to specify any base compile options. This is a great addition. Others include the RPGPPOPT, which allows you to control when the RPG compiler is used to process conditional compilation, and the support that has been added for qualified data structures, array data structures, and the LIKEDS keyword. There are restrictions, but this level of continued support is really quite welcome, and it belies the idea that RPG is dead. In fact, in an effort to be even more friendly to "outside" users, the precompiler now provides alternate names for the SQLCA data structure that better correspond to non-iSeries standards.

Finally, some of you may have heard that embedded SQL will be working with /free. I've heard little bits and pieces from people who claim to be in the know. Well, here's the real scoop, straight from the source:

"Each SQL statement must begin with EXEC SQL and end with a semicolon (;). The EXEC SQL keywords must be on one line. The remaining part of the SQL statement can be on more than one line. Example: An UPDATE statement coded in free-form might be coded in the following way:

Bracketed comments (/*...*/) are allowed within embedded SQL statements between positions 8 through 80 and whenever a blank is allowed, except between the keywords EXEC and SQL. Comments can span any number of lines. Single-line comments (//) can also be used. SQL statements can be contained on one or more lines. To continue an SQL statement across multiple lines, the SQL statement can be split wherever a blank is allowed. The plus sign (+) can be used to indicate a continuation of a string constant. The literal continues with the first nonblank character on the next line."

That is just hot, Gina! Many programmers will be singing your praises from this day forward!

RPG Compiler

But let's not forget the RPG compiler. The RPG compiler has undergone vast, fundamental changes over the years, especially over recent years. ILE RPG forever changed the character of the language, opening up possibilities that we could only dream of in prior incarnations of the language. The changes range from features that are so big you lose sight of them down to recent tweaks that just make life easier. Barbara gave me her take on many of those features.

Huge things include varying fields, which did nothing less than change the way we view string manipulation in RPG (how people did CGI without varying fields is beyond me). Qualified names (and long names in general) have moved RPG out of its cryptic past into a readable language in which the code helps document itself (please, though, don't use the word "self-documenting" unless you want to hear me rant for about an hour). Love 'em or hate 'em, /free calculations are here to stay, and they're a gigantic change to how we write RPG. The MONITOR opcode brings RPG error checking into the new millennium. And then there's that whole subprocedure/prototype thing.

Now that's a lot of change for a language. You might say that these things were all needed and maybe even late in coming, but that's not the issue at hand. We're talking about evolution, and RPG is doing it. In the same time frame, about the only fundamental change to the Java language has been the addition of generics. Hardly earth-shattering. And other than the shoehorning of the languages into the .NET paradigm (something IBM did much more elegantly and successfully with ILE), not much has happened in the Microsoft world either.

Personally, I would add the entire Java integration piece, including the recently added capability to dump the stack trace. RPG works together with Java better than any other language available to programmers today, which just reinforces the idea that the RPG/Java/JSP architecture is the next great programming paradigm.

And that's just the beginning. Barbara lists a number of other things, both past and present. Oldies but goodies include how SORTA sorts overlay arrays (one of my personal favorites). The indicator data structure helped remove our dependence on the old *IN syntax, while %dec(string), %editc, and %editw brought the power of RPG formatting into our little programming hands, letting us distance ourselves just a little bit more from the 5250. Finally, the (E) extender allows us to control our error handling, letting us be proactive rather than reactive.

Newer changes that made the list include things like %subarr (something that's been needed forever) and the date/time conversion capabilities of %dec. Many folks love the %kds and key field list extensions to the native I/O opcodes, while those of us who use FEOD should know about the FEOD(N) extender, which pushes the changes to the database without necessarily writing the records; tidy performance gains can be gotten there. The list is rounded out with data structure arrays and the *TRIM option on parameters.

Just looking at this list, it's inconceivable to me that someone could call RPG a dead language or make the claim that IBM does not consider it strategic. You can complain all you want that it's not taught in schools and it's not cross-platform and on and on and on, but the truth is that if you want a powerful, evolving language to build your business logic, there's nothing like RPG.

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, Eclipse: Step by Step, and WDSC: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

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 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 Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

Legacy application modernization: A comprehensive approach to modernize your business

How Low Code Helps Businesses Modernize their IBM i Apps

Why Migrate When You Can Modernize?