For some RPG developers, Open Access (OA) is considered new technology, for others it is viewed as new architecture. Simply defining OA is a difficult task because it can do so much, including refacing, refactoring and/or new development of applications.
In this post we examine the way OA enables control of new elements within your application. We also look at how to transtion to a true multi-tier architecture.
OA gives developers control of these 4 fundamental areas:
- The I/O memory
- The UI metadata
- The communication channel
- The Multi-tier capacity
Figure 1: The new control capabilities of OA
1. Control of the full I/O memory capability
Every time a write record format is processed by the RPG program the OA handler receives the entire record content.
This control of the different record formats can be particularly significant for display files.
With the 5250 work-station, limitations are imposed on the number of formats that can be displayed, the sequence of the write operations, overlays for record formats and the size of the screen. Another limit is imposed on the total number of subfile rows and the number that can be shown on a screen.
With OA these limitations can be overcome, any written format buffer is available, as well as any field value, including hidden fields. The OA handler for a graphical UI can show more formats and more subfile rows. In addition, an OA handler is not restricted to reading only those record formats that have been written to the device.
Figure 2: Using an iceberg analogy for an application, with the 5250 datastream you can only see the visual output (the peak above the water), with OA you have access to all the data that is available to your RPG program
2. Control of the communication channel
When an RPG program performs an I/O operation on a system file, a system data management function is called to handle the operation. When an RPG program performs an I/O operation on an Open Access file, the OA handler is called.
The OA handler can process the RPG I/O and direct it to new channels and/or protocols.
3. Control of the multi-tier capacity
OA decouples the I/O access from end-to-end, and as such, it provides a multi-tier architecture for RPG.
With OA you can change DB access or the UI without changing your RPG business logic code.
Figure 4: DB access and UI access are decoupled with OA
4. Control of the UI metadata
Metadata is data describing your I/O fields. You may have metadata within your DDL or DDS that describes your files, or you may have metadata which describes new elements for a new device or a resource your OA handler is connected to.
Depending on your OA implementation, you may need to access this metadata from different processing languages or tiers. With OA you have full control over the format, extraction and location of the metadata. The Open Access developer has many choices for encoding metadata. XML can be used to support multiple platforms and use cases. JSON is sometimes used when the consuming client is a web browser.
XML is a cross platform and industry standard to define metadata. It can be validated against a DTD, and can describe constants or literals in Unicode (DDS based storage lacks this ability). It is a perfect candidate for the storing and sharing of metadata for any OA implementation and extension. In addition, processing of XML is directly supported by RPG's XML-INTO and XML-SAX operations codes.
Figure 5: DDS metadata and new metadata can both be stored in XML
How to use XML for metadata from DDS and other source:
The OA handler uses the name of the file as its reference and does not require the file to be present at run-time. Therefore metadata does not need to be tied to the object file. You can generate metadata from different sources and store it anywhere.
Stay tuned for more info or take a look here for a few pieces of useful info: www.looksoftware.com/solutions/rpg-open-access
IBM i ISV Advisory Council