You are currently on IBM Systems Media’s archival website. Click here to view our new website.


RPG Open Access Revisited

For this month’s column, we thought we’d revisit the subject of RPG Open Access (OA). Why? Because during several conversations at recent conferences it became obvious to us that IBM’s initial decision to charge for the feature caused many people to simply ignore it. They took a quick look, decided that there was no immediate payback and therefore no way they could persuade their management to buy the product. They simply walked away.

By the time Rational saw the error of its ways and decided that OA should be available as part of the compiler, a decision we applaud, it was too late and the window of opportunity had passed.

Another factor is that so much of the emphasis at OA’s announcement was on updating 5250 applications that the wealth of other potential uses for it were completely missed, and that’s sad because OA has a lot to offer. We’ve also been told on many occasions that there’s a dearth of education in the realm of OA, so by going back to the beginning we’re hoping to remedy that situation in this new series.

Why OA?

We thought we’d start by looking at some of the questions we get asked when we discuss OA with RPGers. A common question is “Why did IBM bother with Open Access?” This is often hand-in-hand with “Why didn’t IBM simply add browser handling to RPG?” Ignoring for the moment that there’s nothing “simple” about adding browser support to the language, there are a number of points to make here.

First, the question tends to make the assumption that OA is only intended for 5250 replacement. We understand how people might get this impression because that’s where all the big publicity and the vendor activity has been. However, such an emphasis misses the point to a very large extent.

Second, the real answer to “Why OA?” is that IBM simply can’t get new features into our hands fast enough. Perhaps more to the point, even if it were to develop them faster, we as the user community tend to take far too long to adopt them. The result is that even if IBM were to identify a need in the marketplace, code and release it within a matter of months, it would still be some two to three years in total before a significant percentage of the user community could use it. Why? Because we typically take 12 to 24 months to deploy new releases. It is this reluctance that has caused IBM to look to Technology Refreshes as the preferred release mechanism, and of course to introduce OA.

Third, most modern languages have some form of API or other integration mechanism through which new features can be added. RPG of course also has such a mechanism; it’s known as Service Programs. But new interfaces presented in the form of subprocedures don’t “feel” like RPG to many folks. To understand why, think for a moment about what happens when you run an EXFMT. The compiler-generated code gathers all of the fields in the record format together, places them in the buffer along with any required indicators, sets up the user interaction with the device, and, following the user interaction, proceeds to distribute the input capable fields and indicators in the buffer to their respective storage locations back in the program again. Having done so, it then wakes up your program and continues running your logic.

That’s a lot of data gathering and distribution that, when you’re using an API model, you typically must code by hand. Admittedly, operation codes such as RPG’s recent EVAL-CORR (Evaluate Corresponding) can alleviate this tedium somewhat, but nevertheless there’s an amount of work involved that RPGers aren’t accustomed to doing. They basically expect to wave their magic wands (EXFMT, CHAIN, READE, etc.) and have data magically appear in the appropriate spots. With an API interface, that just doesn’t happen in the same way.

When the idea of an RPG browser implementation was first floated we admit that we felt that it was unnecessary and that using APIs just wasn’t that hard. Perhaps our experience with other languages that didn’t do as much work for you made us feel that way. In recent years though we’ve come to realize that it’s the ease-of-use of the RPG approach that in many ways characterized the language. We still strongly disagree with those who believe that IBM should add a browser interface to RPG. We think that OA is a much better choice because it opens so many more doors.

Our industry is changing so quickly that we need a flexible approach that will allow us to interface to any device. Not just the ones we know about today, but those that will join them tomorrow. OA gives us that potential. It doesn’t matter whether the device is a Web browser, a mobile phone, a Web service, an Excel spreadsheet, a simple CSV file or perhaps even a lightsaber. By implementing the appropriate handlers, it becomes possible for RPG to access such devices even if IBM has never even thought about them.

Since OA handlers are just programs (or subprocedures for that matter), they can do anything that the language in which they’re written permits. A handler could effectively be written in C or C++ or Java or PHP or, of course, RPG. In fact, the majority of the handlers we’ve written to date have been written in RPG although many of them do interface with C and Java functions.

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Are You Multilingual?

Rational enables development in multiplatform environments

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters