« Still at Home Due to Volcanic Ash | Main | Assorted Conference Musings »

April 27, 2010



I was really surprised about the complaining of cost. As I understand it, it's roughly $500-$1500. I spent that on my last laptop! How is that prohibitive? I don't get it.


Tami, it's not the amount that's the issue ... it's the fact that there's a charge at all.

A lot of people think (myself included) that, for something like this, the runtime should be bundled into the base OS.

Hans Boldt

Jon, Susan: Here's the way I see it: Open Access provides a different way to call a procedure, but with a few key differences from CALL: 1) Your calls must fit into the RPG I/O model; and 2) your procedure invocation goes through a few extra layers of procedure calls under the covers.

Why the excitement? I'm not sure I understand. If it's to help web-enable existing apps, don't we already have that with WebFacing?

If it's to help code new web-enabled apps, isn't it better to design your app to fit better with the web model? That is, shouldn't apps be written from the point of view of clients making calls into the app code?

Or is the purpose of Web Access simply to generate some buzz about RPG?

As I've opined elsewhere, this leaves me rather pessimistic about RPG's future. This seems like an unfortunate diversion from what could have been done to support and improve web-enablement.


Ron Newman

David & Tami,

I can see both of your points of view. While I like to get things at no additional cost I can also see that $500- $1500 is not that much compared to other tools that are out there for the i system. What I do not get is all the talk about third party vendors developing ‘Handlers’ to make the Open Access product work. I was under the impression that in house developers would be able to develop these handlers for there shops on their own.
I do have a problem having to pay for the product and then pay again to get a Handler.
I may be way off base here but this is my understanding


Bundling it in the base OS was always the a big factor in supporting the i platform.

That is what gives it the edge.

Ronnie (RSA)

Dan Devoe

The way I understand it, is the application handler will be able to format the data to various types of output devices -- such as a Blackberry, iPhone, web browser, or 5250 screen.

It will perform screen I/O based on the type of device -- I wouldn't be surprised if you hear "there's an app for that" pretty soon... :-)

Aaron Bartell


Given your previous involvement in the RPG compiler team and the comment above, what things would you add to RPG to make it a better web language?

Aaron Bartell

Hans Boldt

Aaron: I would add features to make it easier to process requests and call web services.

For example, one enhancement could be to make the various protocols more transparent. That is, for any request that comes in (either HTTP, or SOAP, or XML-RPC, or whatever new comes along), the request gets translated automatically into a call to an RPG procedure, with each parameter converted appropriately.

(Actually, I think it might be possible to implement this outside of the compiler. Think of a "mod_rpg" module for Apache.)

Likewise, calling web services should be as easy as calling a procedure. Under the covers, the call could be converted into the appropriate web protocol.

(Again, this could possibly be done outside the compiler with a tool that automatically converts WSDL to a set of RPG procedures.)

A useful pre-requisite for these would be a better string data type, where string variables are simply pointers pointing into a managed string pool.

Nathan Andelin

The problem with comparing the cost of RPGOA to that of a PC is that you should follow-up and compare the value along with other attributes of each.

As Hans expressed, RPGOA is essentially an additional way to call programs and procedures and share data structures between the two. A PC is a complete system. On scales of capability, innovation, use, and usefulness, there would be vast ranges of differences between the two.

Someone (not me) surmised that IBM (marketing) packaged RPGOA as a separate product, and gave it a separate price, because they really don't understand what it is. It's a feature of the RPG compiler. Does it make sense to portray it as different, and more than that?

While RPGOA may play a role in communicating with contemporary devices, that role might be like the first half octave on a grand piano keyboard.

Given that RPGOA is an additional interface for evoking programs and procedures, is it worth ordering a separate product just for that? Or should we just use procedural interfaces to evoke I/O handlers directly?


Aaron Bartell

Hans, the issue I have with the focus of your enhancements is that it is focused on the move OFF OF the IBMi. Because of my involvement with RPG-XML Suite ( I have been in contact with literally hundreds of RPG shops wanting to do XML web services. The beef I have is that many shops need to do web services only because RPG wasn't pursued as the modern UI layer and instead it is often offloaded to Java or .NET - THUS REQUIRING SOME PROTOCOL TO ACCESS EXISTING BUSINESS LOGIC. And that protocol is often XML.

In my opinion the only time you should be doing web services is when there is a need to communicate with a third party. The .NET developers down the hall in the same company are not a third party. Or said differently, when you control both ends of the spectrum it would be wise to NOT implement an XML transport layer to talk from the back-end system to the front end system. Keep the modern UI within RPG and you can eliminate a lot of headaches.

Not saying better XML support wouldn't be welcomed in RPG, but it is many times only warranted because of moving processing off of the IBMi.

The comments to this entry are closed.