RPG: Not Dead Yet

Wow. One of the things you learn very quickly when writing a blog like this is that you never can tell what subjects will result in reader comments and which won't. Of course with a subject such as "RPG is Dead ..." we expected a few comments, but given that the original article was also open to comments the number of posts surprised us. Our post was even mentioned in the Angus blog.

One thing Mel's original post succeeded in doing is to get RPGers thinking--and talking--about why RPG is a great language and is indeed being used routinely to create new and modern business applications. Maybe that was his intent all along--to get the community to rally around the great language that is today's RPG. We could always give him the benefit of the doubt on that. ...

In terms of RPG being an "old fashioned" language, many situations in the IBM i world contribute to this perception. Not the least being the number of IBM i ISVs that continue to deliver software written in RPG III. And these are the big guys, the ones with multiple 0s at the end of their annual licence fees. We're not sure what they do with all those dollars. Maybe they need it because maintaining the old RPG/400 code is so much less productive than the newer, more modern syntax?

Several customers that we have talked to recently use heavily modified versions of one of the biggest ERP packages in the IBM i community. They had all stopped implementing maintenance releases as they had reached a point where applying the fixes to their heavily modified code was just not practical. They either did not need the enhancements or had already implemented similar features on their own. However, as part of their move to V6 it was necessary to update to the latest level. These are go-ahead shops who long, long ago moved all their own code to RPG IV. Imagine their disappointment when they discovered that this expensive "latest and greatest" release was still predominantly RPG III with RPG IV
being apparently used only in cases where the size of the program had exceeded RPG III's limits!

It's hard to understand why ISVs wouldn't convert their programs, if only to help with on-going maintenance chores. The two RPG flavors (as long as you stay away from the pure ILE aspects) are so compatible that the package in question has actually been successfully converted to RPG IV by relatively small shops (in one case by a one-man-band) that recognized the benefits of making the transition and got tired of waiting for the ISV. Just the extra white space alone, let alone tooling such as Rational Developer for Power and all of the other features of RPG IV, makes it so much easier to read and maintain compared with RPG III.

We've always been surprised that IBM hasn't applied more pressure (or incentive?) to large ISVs to keep their applications even moderately up to date with the modern system's capabilities. Strangely, we heard recently that one such ISV announced that their next release will require IBM i 7.1. Dare we hope this is a signal that their application code has been modernized to require it? Nah, that would be too much to expect.
 

Comments

[Greg Helton]

A RPG programmer was showing me his iPad which he really liked but, he was upset he had to pay for the mouse separately. LOL

Back to the subject at hand. IBM could easily fix the situation by deprecating the C spec. And the I spec. And the O spec. And BEGSR. IBM should announce end of life on those features of RPG. And System/36 mode. If I were Trevor, I would ask every programmer to pledge to not use any feature of RPG that is older than he is.

I have gravely doubt that the ISV requiring 7.1 is doing so because they've updated their code base. No customer of their's would be willing to pay for the update.

I'm taking a free Javascript course at codeyear.com and so are 452155 others.

[Aaron Bartell]

>the number of posts surprised us

There would be even more if iProDeveloper hadn't started suppressing them. I had a couple I posted that never appeared and it sounds like Nathan Andelin did also.

At the end of the day I do realize it's their site and they can suppress who they want.

There are many good people at iProDeveloper so I am hoping they don't just hope this will quickly fade and people will forget - they wronged the community they serve and need to convey where they stand.

AaronBartell.com

[Nathan Andelin]

The comment I tried to post several times at the iProDeveloper site was a slightly abbreviated version of the comment I posted here, yesterday. Fortunately, I saved a copy locally. It can be really frustrating to put thought into civil expression then lose the words for whatever reason.

Mel Beckman says we need an object oriented language. No, we need a record oriented language. RPG offers that kind of interface. Open Access for RPG is a step in the right direction.

IBM i provides an application server environment that is unmatched. I'm referring to the way that IBM i manages workloads. It supports thousands of concurrent jobs.

You lose that when you deploy under a Java or PHP or whatever application server environment. RPG uses shared memory interfaces to interact with IBM i. You lose that when you deploy under a separate virtual machine environment.

How efficiently do you want your applications to run? Do you want to burden them with unnecessary overhead? Do you want to add unnecessary layers of architecture between your database and your user interface? No, ILE languages play a very important role.

[Greg Helton]

I disagree with some earlier comments. I believe that Open Access is just another way to make API calls so it is hardly revolutionary. Whatever a vendor provides through Open Access could be provided just as easily via a traditional API. Open Access returns various record formats just as other AS400 APIs do. There's nothing new in Open Access.

Next, another comment seems to promise that the IBM i scales better than the internet. Do internet applications not share memory? As the gentleman says, the IBM i supports thousands of concurrent jobs. Imagine running Facebook on an IBM i. Thousands of concurrent jobs might not be sufficient.

Programs do run very efficiently on the IBM i but the world seems not to care. A friend just told me that a very big AS400 shop in my town is going to become a very small AS400 shop. I guess those guys finally wrote their last 15000 line, 3 subroutine program.

[Nathan Andelin]

A lot of Facebook content is static. I probably wouldn't use IBM i for hosting or serving that. But any part of Facebook that is dynamically generated from applications that require a database I/O would be a good fit for IBM i.

Of course you wouldn't generate dynamic content for 900 million users on just one IBM i server. But you could host the login service on one server. Then upon successful authentication, redirect users to "their" server; the one that hosts their data and perhaps that of their connections.

Actually there are probably a number of techniques for distributing data across multiple IBM i servers, and I'm not sure what the best architecture might be. But I am sure that whatever architecture you conclude on, it wouldn't be dependent on your choice of database, or operating system, or hardware.

IBM i on Power might give you more options though, because you could host a single instance on 4 cores up to 256 cores.

You couldn't have 900 million concurrent "sessions" on a single IBM i server. But the same is true for all other environments. My point is that RPG "sessions" running in the native IBM i environment are a lot more efficient and a lot more effectively managed than "sessions" running under .Net, JEE, and PHP.

[Greg Helton]

Nathan,
The IBM i does seem to provide effective job management (batch immediate jobs sounds like a good solution) but a year or two ago, there was no disagreement on the System i forums when several people complained about the high latency experienced when executing database functions from server side clients.

For several years I wrote SQL-RPG programs that used native IO to build relatively small result sets that were returned to server side Java programs and from there returned to web clients. A contractor was the first to tell me that his Ajax was slow by a full second. Others on the System i forums agreed.

Mel has a point. RPG is crippled because it runs on only one platform. There is a need for a RPG compiler for other platforms. As it is now, IBM uses RPG as a means to lock customers into the IBM i. And since the cost of learning RPG is essentially the cost of an IBM i, RPG will continue to wither.

[Nathan Andelin]

One reader of this blog wrote to me privately and asked if I might reply to Greg Helton's last message.

Regarding the performance of returning a small result set from RPG programs to Java clients, Greg didn't provide enough detail for me to assess the problem, and I don't know what forum discussion he was referring to, so I can't address that problem directly.

I'm aware of quite a few people who evoke RPG programs from Java, who say that it improves performance, and that RPG is a better language for implementing data validation, business logic, and transaction processing.

Some people evoke RPG from Java rather than using JDBC interfaces to access a database, just because JDBC is so difficult to secure.

If you run into performance problems by evoking RPG programs from Java, consider the opposite scenario. What about evoking Java programs from RPG? That's where I notice a REALLY BIG performance hit. As a generalization RPG is many times more efficient than Java, PHP, and aspx .Net interfaces.

Regarding the allegation of RPG being crippled by running on just one platform, that is a red herring for the vast majority of organizations, including most small to medium sized software vendors. In most cases, even with Java and PHP, most organizations will settle on just one platform. It appears to me that only the largest vendors have the resources needed to support multiple platforms.

Even the word "platform" in inadequate. It's not that Java is platform independent; rather Java IS a platform. IBM i is a platform. They may both run on the same hardware and share a small number of low level interfaces, but the vast majority of interfaces between Java and the native IBM i environment occur through sockets - as if they were running on separate servers.

I could say a lot more about getting the best possible performance and scalability from IBM i while supporting web clients, but suffice it to say, the native IBM i environment and ILE languages play key roles.

[Curtis Dumke]

I'm 73. If I should not be using any part of RPG that is older then me what part is that?

Curt Dumke

[Greg Helton]

Just to be clear, I've stated that JDBC on the AS400 was noted to be slow by a few people in the System i magazine forums. I never said that JDBC+SQL was faster or slower than JDBC+RPG_stored_procs. I never said anything about SQL. I wrote SQL-RPG programs that used native IO. Nathan is preaching to the choir in his defense of RPG versus SQL.

In the System i magazine forum, no one presented any technical info, there was just common agreement that JDBC connecting to the AS400 was slow. I've never seen any evidence to the contrary.

The reason I wrote SQL-RPG programs is because I agree that pure SQL on the AS400 can be slow. SQL-RPG client programs using native IO can be and probably always is faster when the database was not developed with SQL in mind.

Talk about red herring - "It appears to me that only the largest vendors have the resources needed to support multiple platforms." ... ever heard of "Write Once, Run Anywhere"? Java is a vendor's dream. I, however, prefer open source to vendor dependency. The last vendor I want to talk to is one that will lock me into the AS400. I don't want to be locked in to any hardware (although I got my first Mac because it ran on a chip from the same family as the AS400 and everything I ran in QSHELL would run in the Mac's command terminal).

For many, RPG was their first language. Today, people learn Javascript using a text editor and a browser. They may download Visual Studio Express from MSDN or a LAMP stack from Bitnami and they will invest in those skills. The green screen is never going to impress those programmers. The fraction of developers coding RPG is starting to resemble the few remaining septuagenarians who speak a disappearing dialect.

We also have an example of red herring engineering. The answer to the problem that 'calling RPG from Java is slow' is 'Well, if that is slow, try calling Java from RPG cuz that is REALLY SLOW'. This is hardly the first time I've encountered an RPG programmer presenting a non sequitur as his argument.

As Nathan states, calling Java from the RPG is slow on the AS400 and the reverse is also true. Yes, the AS400 can be slow. Any number of RPG programmers can attest to the AS400 & IBM i being slow when executing SQL, the language normally used for data retrieval. All solid arguments against the AS400 & IBM i.

Is RPG a better language for implementing data validation as Nathan states? Are we comparing RPG to Java or SQL? An IF statement in RPG looks a whole lot like an IF statement in Java. Table lookups are good for validation in RPG but in Java, I'd use a Map or an ArrayList to accomplish the same thing. I'm going to call this a tie.

Just as Nathan cannot find the forum in which a few of us noted that AS400 JDBC is slow, I can find no mention of JDBC being difficult to secure. Unless you're talking about SQL injection which isn't about securing JDBC.

Many millions of business get by just fine without the IBM i today so it would be delusional to pretend that it offers some crucial advantage.

Is RPG many times more efficient than Java, PHP or .Net? Not by any measure that most of the world cares about. Its great for batch. Its great for green screen. For the new applications being built today, there's no need for it.

[Ken Kopal]

Having been in management most of my career and currently having both RPG and Java developers working for me I am kind of pulled both ways. I have worked in multiple Java shops and this magical frame work they brag about can also become so big and cumbersome that it is extremely difficult to work with. It is kind of like one of those 15000 line, 3 subroutine RPG programs. Both RPG and Java can write reusable code but I have seen both rewrite the same code over and over again with each time being a little different. I believe one of the reason RPG will die (I know Aaron will not want to hear this) is the aging work force. I have read several hundred RPG developers resumes in the past couple of years and the vast majorities have not and really do not want to move beyond RPGIII. Most are just looking for somewhere to fade away into a green screen. Where I work, we are an ISV and we are forcing developers to convert to use the modern tool set like SQL, ILE, and Open Access but I have a hard time getting some to use RDi. The other killer yet saving factor is the sure number of lines of code written in RPG.

[Aaron Bartell]

After reading Ken's comments I think we need to break things apart a little.

If a language is dead because there is lack of use then all languages go through fluctuations of dying and coming back to life (with RPG doing mostly dying - I do not debate it has been getting used less in the past decade).

BUT what was partly being conveyed in Mel's article is that RPG is incapable of doing modern apps without significant coding and that simply isn't true (as many of us know).

Pretty much the ONLY thing holding RPG back from making forward-popularity-progress is lack of access to IBMi for the next generation of programmers.

AaronBartell.com

[Nathan Andelin]

Greg, you made several references in your last message about the "AS/400" being slow at performing SQL, JDBC, and Java.

The last AS/400 I purchased was at the turn of the century. I still have it, and I agree that it is slow at performing those workloads. IBM had method behind their seeming madness which I could explain, but should we be talking about a 12 year old system? Or should we be talking about the performance of today's IBM i on Power Systems?

Perhaps the best way to test IBM i SQL performance is by using the STRSQL command line interface. You will see that SQL performance under IBM i on Power surpasses the vast majority of other platforms.

The problem is that additional interface layers such as JDBC, object-relational mapping, inter-process communications, mapping between "business objects" and "user interface object", and finally generating formatted streams for desktop and mobile clients adds a lot of additional CPU requirements as well as latency. Yet that kind of distributed architecture, mapping data from one type of object to another, each having their unique formatting requirements over multiple layers is what you find in the majority of Java applications.

That type of distributed architecture doesn't run any faster on other platforms. In every case it's just a lot of unnecessary architecture between your database and your desktop or mobile clients.

This discussion about iDeveloper Pro pronouncing the death of RPG has spread to a number of discussion spaces, one of which I started on Linkedin:

http://www.linkedin.com/groups?home=&gid=1107217

There I shared links to an RPG program (including source code) that simulates a meeting/chat service between 4 clients.

For brevity sake, I won't repeat the browser events that the RPG program responds to in this blog, but since you raised a concern about performance, I will share that when a new chat message is posted to the server, the elapsed time between that event, and the 4 chat clients receiving a copy of that message is 4 milliseconds.

When I say 4 milliseconds, I'm talking about the elapsed time from the client's perspective, to receive 4 responses to 4 individual requests. That includes LAN latency. The amount of time for the HTTP server and the RPG application to respond to 4 requests is something like 1 millisecond.

I've seen a number of browser chat services written in Java and PHP, most of which poll the server at regular intervals. The code and interfaces are messy and clunky. And they don't deliver simultaneous responses to participants in the meeting.

Well, if you're interested in it, you can find it on Linkedin.

[Greg Helton]

I was just remembering the RPG programmer whose SQL-RPG program had recently been implemented in production. He told us he had a problem, "The program has been running 36 hours and it is still opening the cursor".

Yep, I agree, SQL performance on the IBM i surpasses most other platforms.

But most IBM i databases date back to the System/38 or S/36. They aren't relational and they weren't created to work with SQL and they work very poorly with SQL.

It is really funny to introduce an experienced developer to the IBM i & try to get him to comprehend that you have a database that is really fast but performs poorly with SQL.

The reason the IBM i is falling to the wayside is that the non-relational database does not work well with the tools developers use today. Sure, a few developers are doing the right thing but as many others have said, few are updating their legacy code and few are updating their legacy skills. This is true on every platform, not just the i.

Thanks for the link to the chatroom code on linked-in. I am in the middle of a classroom assignment for a chatroom coded to run on node.js. I'll compare the two.

[Tak Yiu Lai]

"The program has been running 36 hours and it is still opening the cursor". I believe this type of performance issue can normally be resolved by using SQL analyzer or STRDBMON. Then you can create the proper SQL index regardless it is relational or not. This should not be used as an excuse to kill RPGx.

I do agree RPGx is drying up recently because of so many reasons I don't have to repeat. IBM must add unique features on RPGx so that it has certain edges that people can't resist using it.