Open Access for RPG Grabs Attention at COMMON

May 10, 2010 Dan Burger

RPG is king. If you don’t believe it, go to COMMON. OK, it is the big fish in the small pond scenario if you’re looking at the entire IT universe, but these are IBM i enthusiasts and for the majority of them RPG rules. If you are curious about the reaction to the tool IBM calls the Rational Open Access RPG Edition and that everyone else calls RPG Open Access, you wouldn’t be the Lone Ranger.

Educational sessions presented by IBMers and sessions presented by ISVs such as Profound Logic and looksoftware were filled with interested programmers. In some cases, extra sessions were added to the schedule to accommodate the flock. I’m not saying people were lined up around the block, or chanting R-O-A, or that some type of mania is causing RPGers to tremble with excitement, but people clearly are interested in what this can do for them.

George Farr, one of IBM’s application development tools experts for Power Systems, told me he and Satish Gungabeesoon had more than 150 attendees in their first Open Access class, which caused a second class to be added. Gungabeesoon is a software architect at the IBM Toronto Labs and an expert in RPG Open Access.

For those who are unfamiliar with the open access feature, it uses the native RPG I/O access methods for accessing the native database (DB2/400 or DB2 for i) and outputs information to screens or other applications written in other languages and then allows that data to be presented in a browser rather than a 5250 screen. To accomplish this requires the use of a “handler,” a different kind of data stream, which is where ISVs will factor into the process. IBM and the third-party vendors have created similar pathways for this end result for years, but this native method for using RPG is new. It’s a different way to interface with XML docs, Web services, spreadsheet programs, databases, or cloud computing facilities beyond the iron that runs the RPG applications.

Perhaps the greatest appeal is that it allows RPG programmers to use familiar I/O access methods to build the handlers that communicate with a variety of external devices.

In the early going, the discussions about ROA have been wild and wooly. What it is and what it isn’t depends on the source. Let’s just say it’s early in the game and it’s the score at the end of the game that really counts.

Alex Roytman, chief executive officer of Profound Logic, presented multiple sessions on the topic of Open Access and, more specifically, his company’s just-released software called Profound UI that uses this technology.

In a conversation with Roytman, who obviously has a dog in this fight, he was eager to explain some points that were made by competitors BCD and LANSA in an article published in The Four Hundred two weeks ago. Those two vendors, in case you are unaware, also have dogs in this fight.

One of the points Roytman wishes to clarify is that RPG Open Access requires a major change in source code.

“This is not exactly true,” he says speaking from his own experience. “I cannot speak for other handlers, but with Profound UI (the handler written by Profound Logic), you don’t need to change RPG code, other than adding the handler keyword.”

In his example, a program with 20,000 lines of code would only need to change a half line of code to modernize it because the handler would handle the real work.

When I asked Farr about this, he concurred saying, “The only thing you need to change is to add the handler key word that identifies where the handler code is located.”

Will there be instances involving more source code changes because a specific handler does not address all the end user’s requirements? I suspect so.

The question of maintaining separate copies of source code–one for the green-screen application and one for whatever it is that you are pushing out–is another issue Roytman wanted to address. “There are about a dozen simple ways to avoid keeping separate source code,” he says. Two that he uses as examples are simple conditional compiling and creating programs that can detect the context they are running in. Any debate about statefulness versus statelessness can also lead to misconceptions, Roytman says.

“Business developers and RPG developers prefer to code in a stateful way, but the Web makes you code in a stateless way,” he points out. “In the past, the solution was to rewrite your code. While this is an extremely difficult problem, Profound UI has solved it. RPG programmers can now code in a stateful way (or reuse existing stateful RPG applications by adding a single handler keyword), and have all of their work be compatible with the stateless nature of the Web. It opens up so many possibilities,” Roytman says.

Farr backs this up by saying, “In stateful versus stateless, your handler is the code that keeps state. In ROA, we are giving all the information to the handler. It is up to the person writing the handler to use it.”

Differences of opinion on how to accomplish an objective are what ultimately make certain products more successful than others.

Farr says he has no issues with the approaches taken by companies such as LANSA and BCD.

“There are people–like LANSA, for instance–who say, ‘We are not getting into this.’ They have already done something to compensate for what Rational Open Access, RPG Edition does. Like any other enhancements IBM has done, if it works for you great, if it does not then do something else.”

A comment from RPG experts Jon Paris and Susan Gantner, snipped from their iDevelop column in IBM Systems Magazine, made a similar point. “. . . even though we’re big fans of RPG Open Access, we don’t think this is ‘the’ way of all future RPG coding or even all future RPG Web applications. One size definitely does not fit all, especially in today’s RPG community.”

As Paris and Gantner go on to say, the important thing for application developers is to keep moving forward.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search