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

IBM i > DEVELOPER > RPG

The Open Standard for RPG OA Metadata


In 2010, IBM announced RPG Open Access, allowing a program to directly receive input and output without going through the workstation controller, printer or disk controller. This was a significant step forward for RPG because it enabled RPG to support modern environments and devices as well as many other capabilities that were previously not viable (Figure 1). The most significant feature to be explored so far has been at the user interface (UI) layer, removing the limitations of 5250 that have constrained RPG UIs for so long. Developing rich, graphical applications that support Web browsers and mobile technologies such as the iPhone, iPad and Android devices using an RPG skill set alone is a positive and far-reaching development. However, Open Access can do much, much more. Examples such as taking printer output directly to Microsoft Excel or other external data sources are just the beginning.

At the 2011 COMMON conference in Minneapolis, IBM met with a group of interested parties to advance the establishment of an open standard format for the metadata used by RPG Open Access handlers. After continued collaboration, the standard was announced a year later at the 2012 COMMON conference in Anaheim, Calif., by IBM and members of the Open Standard consortium.

IBM anticipated that the IBM i community would come together around RPG Open Access, says Steve Will, IBM i chief architect. “IBM i clients have always had a very strong community, with many highly skilled developers in the customer and ISV ranks. When IBM created RPG Open Access, it was a key design point that IBM would provide a very open interface. It’s our belief that creating detailed interface specifications from IBM would limit openness and innovation,” Will says. “The OA Metadata standard, together with the many RPG OA solutions being written by customers and vendors, represent the kind of work we hoped and expected would result from this open community approach.”

Why Create an Open Standard?

The core objective of the open standard is to provide a simple common foundation that can be shared by Open Access implementations. This standard reduces lock-in to a specific implementation and allows multiple solutions to add value to one another. It also ensures that each implementation can support a variety of device types in a simple manner.

Using the standard makes it easier to work across multiple types of handlers from different suppliers. Developing or interacting with a handler is made much easier with a known standard that provides a transparent and extensible architecture. An important benefit of the standard is that it’s simple to implement but doesn’t limit solutions to specific technologies such as a printer or Web browser. This provides a foundation for dealing with today’s requirements while also allowing flexibility to adapt to future innovations.

What Does the Standard Contain?

The standard is a simple single portable definition that’s independent of any particular platform or device. It uses a format that doesn’t require proprietary tools to view or edit. Furthermore, it has a format that can be used natively by as many devices and platforms and programming languages as possible (e.g., RPG, C#, PHP, Objective C, Java) and can be a base definition for conversion to certain devices or specific platforms (e.g., HTML5, Web Services, XAML, PCL).

How Does the Standard Benefit RPG Developers?

First, let’s see how OA really works. Open Access gives the full control of the RPG I/O UI buffer and communication to a handler.

The UI buffer definition can come from a DS (Data Structure) or DDS (Data Definition Specification). The source of the UI description will determine the limit of the definition but the RPG program will only consider the buffer definition. For example, when using a dspf or prtf DDS, all field positioning, constants or DDS keywords will be ignored by the RPG application but Input, Output or Hidden fields will not.

The communication is switched from the reserved System Data Management Function (SDMF) for DISK, PRINTER or WORKSTN, directly to the handler that takes control. The handler can then determine and use any channel to communicate data input and output to and from any other programs or external devices.

Is there anything else the handler needs? Yes, since the handler isn’t tied to the SDMF, it doesn't have the full definition of the UI description. That could be acceptable with database access where you don't need positioning or rarely use DDS keywords, but for display files or printer files this is likely to be an issue. All of the UI description metadata is no longer embedded, which is great from the RPG perspective. This missing information turns out to be one of the major advantages of Open Access, because it can now render your RPG in a true multitier environment. The business logic and the user interface can now be properly separated.

How can we take advantage of this multitier architecture? The IBM i server DDS is a proprietary format that only RPG or COBOL can understand. Previously being tied to only those languages in a monolithic fashion meant that this proprietary format was not an issue.

But now we want to carry the UI definition to new channels or devices and we need to find a way to get the full definition that the DDS held into a format that the user Interface builder can understand. But we require even more; we want to store this definition in an independent entity.

If the UI definition is in a different tier, we can control its content from the outside, add metadata beforehand, create customized versions and even create multilingual versions. The handler could also decide to choose which version to send to the UI at runtime using the current user profile or any contextual information.

When the definitions are held in a simple format, it’s easy, for example, to extract a list of all the labels and convert these to any language for either a single definition or globally. At runtime, the handler only requires a reference to the display name to get the corresponding UI definition, and it can select another version with the new language instead. This is something you couldn't do with the display file on its own because it’s unique and embedded in its library.

When the handler architecture extends the Open Access multitier capability then many aspects of customization or globalization becomes far more agile.

Pascal Polverini works at looksoftware and is part of the IBM i ISV Advisory Council.



Advertisement

Advertisement

2019 Solutions Edition

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

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

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