RPG! Yes you can...

Posted by Trevor Perry on Dec 4, 2012 5:15:00 PM

   

 

Modernization with RPG Open Access

You have an application that looks up the zip code for your US customers and returns the city, county and state. Your RPG program uses a module to retrieve the information, and the module uses an IBM i DB2 database file for the lookup. Each month, or twice each month, the US Postal Service sends an update to their zip code database. There may be 25,000 updates to a database of over 43,000 records. Unless you apply the updates immediately upon arrival, your database would be out of date. A new project must be started to build an entire update process to keep the zip code database in sync.

Within the last decade, we were introduced to SOA - Service Oriented Architecture. Along with the concept of service enabling applications and modularization, a term called loose coupling was something we learned about. The concept was that a tightly coupled application was bound directly to other applications, and where SOA techniques were used, applications could be loosely coupled. In RPG developer terms that might mean the calling program would not have to be recompiled if the called program changed its parameters.

In our zip code retrieval example, if a module was used to access the zip code database, we may be able to change that module to consume a third party web service, and recompile the service program without major impact on all the calling programs. Depending on how we built the application, the worst would be a recompile of all the calling programs after the module was rebuilt.

With RPG Open Access, we have a lot more flexibility. We could write a handler program (in any IBM i HLL) to perform the zip code web service consumption. That handler can be connected to the zip code database file inside the RPG module. When the calling program accesses the module, the module will perform a normal file input operation - as far as it is concerned. Since the handler is connected, there is no longer a database file operation involved, but a call to the handler program. That handler program will use the requested key to consume the web service and return the retrieved zip code information. When the handler returns the values, the RPG module thinks it has performed a file input operation and it continues to perform as it was originally coded.

One advantage of this approach is the minimal code invasion to the application. The handler requires only one F spec keyword to direct file operations to the specified handler program. All the work is performed inside the new handler program you will need to write. (A quick note, consuming web services from an IBM i HLL program is not covered in this blog entry, so if you were to take this approach, you may need additional research!)

A second advantage is that this approach can be used for legacy code where the zip code database file retrieval is performed inside the application code, rather than, or in addition to, the previously mentioned RPG module. The ability to extend your existing application code is limitless with this approach.

A third advantage is that the application is now loosely coupled. If you decide to switch third party providers for the zip code web service consumption, all that is required is the zip code handler program to be rewritten. All other RPG programs and service programs can remain as is, without code invasion or recompile.

The possibilities are endless with RPG Open Access. While I have covered a simple INPUT file situation, OA can be used for any file access - INPUT or OUTPUT. OA can be used for any file that can be used on an F spec in an RPG program - all that is needed is a handler that will work for your situation. looksoftware’s openlook handler is designed to manage all INPUT and OUTPUT for RPG display files. There are several third party software vendors who supply a 5250 replacement OA handler, most of them require their own third party developer tool and/or user client to work.

There is a movement among the current IBM i OA vendors to build a consistent set of OA industry standards and conventions. When that has become pervasive, it should be relatively easy to switch display file handlers as your needs or vendors change. And, as more handlers are written for printer file processing, output database file processing, and so on, using those standards will mean you are ensuring loose coupling no matter which vendor you use.

 

What is RPG Open Access?

While the previous example may have given you some idea of how RPG Open Access works, a more visual explanation is required.

First, let’s look at the current situation with RPG. All file access, input and output, is performed on the IBM i with controller programs. These controllers are built into the operating system, and there are many more than you will ever use. This picture outlines the basic file operations used in a normal IBM i RPG application.

What is RPG Open Access Trevor Perry

For each kind of file operation, you will need a file object. For example, your DSPF file object is created with DDS and then compiled. Your tables may have been created with SQL CREATE TABLE, or with DDS and CRTPF or CRTLF. When the RPG program runs, the file objects are used to communicate with the controller program, which is then used to communicate with the final destination - an emulator or terminal for a DSPF, a spooled file on an output queue for a PRTF, or the stored data on disk for a database file.

With RPG Open Access, you can consider that your handler programs are simply replacing the operating system controller programs. You can now manage the file operations to suit your specific purposes. Each of the handlers in the following diagram will have been written by you or a third party, and will perform a specific function.

Trevor Perry OpenLook RPGOA

For example, you could write a PRTF handler or output file handler to create an XML file. This file could then be sent to a user’s browser for display, to another application for consumption, or to be saved as a database file for another application or another system. You might even build an output file that is sent to a 3D printer to build a model of an item using specifications retrieved by using the item key in your enterprise application. The possibilities are endless and unlimited.

While RPG Open Access is becoming accepted in the industry, there will be some transition before the available handlers will no longer rely on the file objects you are currently using inside your application. For example, there is rich information available inside the DDS for a Display File, however, this is limited in scope and size. Eventually, most third party vendors will supply other techniques to define the file conversation, even if it is simply building the DDS automatically for you and compiling the objects.

Note that this article is not a representation of the complete RPG architecture, but a sample with the most common files used in typical RPG applications - DSPF, PRTF and DB files. Also note that there is no requirement to move all files inside an RPG program to use an OA handler - your RPG program will work fine with any combination of handler enabled and native file access.

 

Where is RPG Open Access useful today?

Until there are more RPG developers familiar with writing Open Access handlers, the IBM i community will be relying on third party vendors to supply handlers for specific application purposes. The most common handler available from the outset has been DSPF handlers to open the 5250 conversation beyond the green screen. looksoftware supplies their DSPF handler - named openlook -with their toolset for modernization. Before OA, the looksoftware suite relied on the 5250 workstation controller, and with their lookdirect product were able to access the interactive-license-free APIs supplied by IBM for their Webfacing tools.

openlook

With the integration of Open Access, the looksoftware suite can access both the 5250 controller inside the operating system and the openlook handler within the same application. If you wish to sign on to your IBM i and access standard menus, there is no RPG and these are delivered with the standard 5250 controller. When your application calls an RPG program using the openlook handler, the looksoftware clients understand this is a continuation of the same conversation, and deliver the screens from that program seamlessly in the correct program stack order. And the same applies when switching from an OA program to a traditional DSPF 5250 program.

For those RPG programs where you include the openlook handler, the first think you will notice is that subfile programs have changed quite drastically. If you RPG program builds multiple subfile pages, traditionally, the emulator would send a request back to the 5250 controller program for the next or previous page when the user presses one of the page keys. The looksoftware client will convert that subfile into a datagrid, and because openlook can see all the records built by the RPG program, they will be immediately delivered to the user. To see more records, the datagrid vertical slider is used without returning control to the IBM i. As you understand the advantage of this architecture, you will be writing new RPG programs to take advantage of this feature.

With openlook, you have the ability to code and control more of your user interface inside your RPG program. As you learn what the out-of-the-box experience can do, the next step is to understand how to control properties of the generated graphical user interface. The looksoftware client will translate the flat 24x80 or 27x132 screen data into a graphical object model. With openlook, all hidden fields that are not displayed with that green screen area are now available to the looksoftware client. These hidden fields can be used to modify or set properties of the generated object model, or they can be added to the user interface to be used for input, output or both. With hidden fields, the amount of data you can now deliver to the user is no longer limited by the screen size as defined by the DDS for the DSPF.

 

What next?

If you are a current looksoftware customer, adding one F spec keyword to your existing RPG programs can enhance your user experience significantly. looksoftware have several videos and recorded webinars to help understand how RPG Open Access and openlook can benefit your RPG development.

If you are an RPG developer, learning what Open Access can do for the future of your RPG applications is the key to the longevity of your development career. Consider OA as another development tool in your toolkit, but one of the most important ones for an RPG shop.