Rational Open Access: RPG Edition, formerly known as RPG Open Access, is a valuable tool in any modernization initiative. Let’s start exploring it in this TechTip.

There have always been quite a few UI modernization tools, some created by IBM, such as the old HATS, and others—many others—created by vendors. Until IBM created RPG Open Access, each tool followed more or less the same theoretical principles, but had its particular implementation. However, Rational Open Access (ROA), RPG Open Access’s newish name, was created to simplify the way an IBM i–based backend and a “modern” frontend can coexist and work together seamlessly. According to IBM: Rational Open Access: RPG Edition provides a way for RPG programmers to use the simple and well-understood RPG I/O model to access resources and devices that are not directly supported by RPG. Open Access opens up RPG's file I/O capabilities, allowing anyone to write innovative I/O handlers to access other devices and resources such as:

• Browsers
• Mobile devices
• Cloud computing resources
• Web services
• External databases
• XML files
• Spreadsheets
• And more”

An Open-Access application has three parts:

• An RPG program that uses standard RPG coding to define an Open Access file and use I/O operations against the file
• A handler procedure or program that is called by Open Access to handle the I/O operations for the file
• The resource or device that the handler is using or communicating with

Open Access is the linkage between parts 1 and 2. Open Access does not provide the handlers. Anyone can write the handlers that extend RPG IV's I/O capabilities to new resources and devices.

• Software tool vendors
• Business partners
• Services organizations
• Users

The provider of the handler can choose the RPG device type whose I/O operations best fit the functions provided by the handler. For example, a user-interface application could map to a WORKSTN file, an Excel document could map to a PRINTER file, and a web service could map to a keyed DISK file.

It seems that IBM created a great tool but left an important piece of it (the handler) to the “users” (you, the programmers). However, because of the way it was built, “software tool vendors” and “business partners” are able to provide you with assistance or even full-on implementations. In any case, there are two possible approaches to ROA: you can write the handler after writing the application, which is probably the most common scenario and certainly the case in a modernization initiative, or you can do it the other way around. IBM describes how to handle (pun intended) both situations:

Scenario 1: The Handler Is Written After the Application Is Written

For example, an existing application that uses 5250 display files is modified to use Open Access for the WORKSTN files.

• The RPG program is modified by adding the HANDLER keyword to the WORKSTN files.
• The handler must handle all the operations and requirements of the existing RPG program.
• This type of handler will often be provided by an outside expert such as a software tool vendor or business partner.

Scenario 2: The Handler Is Written Before the Application Is Written

For example, the RPG programmer wants to use a web service that returns information for a specific set of criteria.

• The handler provider creates a keyed database file matching the web service with a field for each piece of information returned by the web service, and a key field for each criterion needed by the web service. This file will not hold any data; it will be used only for defining externally described files and data structures in the RPG program and the handler.
• The handler provider can tell the RPG programmer what I/O operations the handler will support. For example, it might only support OPEN, CHAIN, CLOSE.
• The RPG programmer codes the RPG program using the file as an externally described keyed DISK file, with the HANDLER keyword to identify the Open Access handler.
• The handler uses externally described data structures defined from the same file.
• This type of handler might be written by the same RPG programmer who uses the Open-Access file, or it might be provided by an outside expert.

How Open Access Works

When an RPG program performs an I/O operation for a system file, a system data management function is called to handle the operation. When an RPG program performs an I/O operation for an Open Access file, the Open Access handler specified in the program (see the example below) is called. The handler receives a data structure parameter with subfields that enable the handler to perform the correct I/O operation and then provide information back to the RPG program.

Handler declaration example (sorry for the fixed-format; it’s IBM’s example, not mine):

Fmyfile   CF   E         WORKSTN HANDLER('MYLIB/MYSRV(hdlMyfile)')

If the file is externally described, it must be available to the RPG compiler at compile time. ROA does not require the file to be present at run-time, but an individual handler may require the file to be present.

More to Come

This seems like a good place to stop. In the next TechTip, I’ll talk about how to tweak your programs to provide a better fit for ROA and tell you about some vendors available to help you take full advantage of this great tool. Until then, your comments, questions, and suggestions are welcome! Stay safe.