The future is now.
There has never been a better time to learn about Open Access (OA). It has now become a mature technology that RPG developers are increasingly adopting. Although ISVs have primarily been using it for creating graphical user interfaces, printing and database solution providers are starting to leverage the OA architecture too.
For you RPG developers who haven't yet delved into OA, how can OA change your perspective?
In addition to the well-known and bulletproof RPG I/O model, with OA you get the additional control of:
- A true multi-tier architecture
- Memory
- Channel
- User interface (UI) definition
More information on this will be published in the upcoming IBM Redbook Modernize IBM i Applications from the Database up to the User Interface and Everything in Between.
What Is the Open Access Metadata Open Standard (OAMOS)?
OAMOS is an open format to describe UI definition and metadata, integrating both DDS definition and a modern graphical UI definition. It's architected to enable developers to switch between UI solutions, reduce lock-in for the end-user, and open up new and exciting technology integration options for the IBM i community. You can convert your legacy DDS within this open format, extend it with a modern UI element description, or create new UI interfaces with the OAMOS format.
To be OAMOS-compliant, your solution will need to either adhere to the open format described in the website or provide an import/export function to the format.
The Open Standard Now Supports JSON
OAMOS serves all Open Access file types, including display, printer, physical, and logical files. Because it's defined using XML, it can cover all device structure and layout metadata definition. For web browser applications, there are now two approaches supported: 1) JSON and 2) XML with XSLT, which can directly produce HTML (HTML is also a form of XML). The standard also includes the possibility to convert XML to JSON and vice versa.
Where Should I Store It, in the DDS or IFS?
A key challenge with RPG modernization has been arising from monolithic blocks of legacy RPG with DDS embedded, as the buffer definition is merged with the layout definition. A legacy DDS describes the buffer definition of your fields and their layouts, but the RPG only contemplates their buffer definition.
Still, using a DDS (that's used for buffer definition) to also store layout definition, even if you use JSON or XML, is missing the point, as the code remains monolithic. This is poor architecture that needs to be addressed.
The key point is that the layout definition of an application needs to be in a separate tier. When your application is based on a truly multi-tier (i.e., model-view-controller, or MVC, architecture), you will have no limitations on any customizations, because then you have interdependent tiers you can operate on. Also, processing logic is easier and more agile to deal with, which is the foundation of a multi-tier architecture.
Another disadvantage of storing metadata in a DDS is that it disables Unicode for any literal constant, since the DDS cannot be compiled with a Unicode code-page. This is a limitation for multi-lingual enablement and is in discrepancy with the World Wide Web environment, limiting international business visibility.
In the IFS, you can save your UI definition and metadata in XML or JSON, in a document that naturally can be set in Unicode. Using an autonomous metadata document will also leverage the multi-tier architecture that OA enables. This is significant because when you are truly multi-tier, any changes or customizations are integrated with any evolutions that you will encounter for your business.
Open Access Runtime and Change Management Considerations
At runtime, only the reference name of the file is used, with a qualified library name or the library list (this is valid also for printer or physical file). Therefore, your solution can use the reference name as an index to any metadata and from any font or base that will serve the UI. Metadata can be stored in the IFS, in any other accessible server, or even in the cloud. Ultimately, your application can leverage first-level customization flexibility using the *LIBL. With a true MVC or multi-tier architecture, you will get the benefits of second-level customization flexibility.
Regarding change management solutions, having metadata within the DDS will require you to deploy only the display file. If you store your metadata in an IFS document, it's easy to anchor it within any change management solution. ISVs using IFS can provide an import/export or deployment process that can be integrated. Therefore, using DDS or IFS to store metadata will not make any difference for your change management perspective.
Performance Considerations
If you store your metadata in the DDS, you'll have to extract it at runtime with an API. This is perfectly acceptable as this performs efficiently and is fast. If you use a document in the IFS, your metadata is already available. In both cases, you will have to send your UI definition to the GUI runtime, and both processes will be equivalent in terms of performance. A structural advantage from the IFS document approach is that it can leverage the cache of the GUI runtime. If you use JSON, interpretative process performance will be improved for a browser-based solution. However, if JSON is used to generate HTML, it would perform faster with XML and XSLT (HTML is a form of XML). In the end, the different storage and format options we consider here are not determinant factors for performance.
Xcase and Tembo AO Have Adopted the Open Standard
Two major ISVs in database modernization have recently adopted the OAMOS, and both contribute to its extension for database use: Resolution's Xcase for i and Tembo's Adsero Optima. This is excellent news for the IBM i community. OAMOS integrates definition and metadata for all file types and therefore physical and logical files. Xcase is implementing an extension to describe DB relationships from any file to any file. This will enhance OAMOS and be available for all the community.
Opening the IBM i UI Definition to New UI Designers and New Programmers
For a modern designer, generating XML code that describes the UI structure and layout is an easy task. If this XML matches the OAMOS, it becomes possible to generate a DDS that then can be used for an RPG compilation.
looksoftware has already leveraged this approach with its Open Display File implementation. A modern graphical screen designer now has no limitations with layout. For example, a developer can design two or more grids side by side (which is impossible purely with DDS) and add all modern UI controls without screen-size limitations. Ultimately, the RPG can control everything, including all UI properties. Now a modern UI definition and metadata (in OAMOS XML) can be shared between a modern designer and the RPG runtime. A DDS, containing only the buffer definition, is generated to serve the RPG compilation. The overall solution is already wonderful, but what if the RPG could directly use the XML for the compilation?
XML as a Replacement for DDS
What would happen if XML replaced DDS entirely? One major advantage would be to enable newcomer RPG developers to entirely embrace all development elements of the IBM i. The recent upgrade of RPG to free-form has helped make RPG more appealing to newcomers. New programmers can use DDL for table definition, but for display and printer files, the use of DDS is definitely a bottleneck as it's an archaic format for defining files. A complete adoption of RPG would need to integrate an open format such as XML to define any files. XML would naturally unleash all the coding processes and highlight the value and investment in RPG.
This XML can be the same and unique source for:
- RPG field buffer definition
- UI definition and layout
- Any device definition elements
This would centralize metadata definition and fulfill the objective of providing a true multi-tier architecture.
Other advantages of eliminating DDS would be:
- Overcome the size limitations (max size 32k/format; field type; 9999 rows/SFL). 16MB per field could be used. Any accepted RPG field type could be integrated (Integer, Boolean, etc.).
- Use new meta-structures. A field could be defined as an array or as a data structure.
- Enable long names for formats and fields.
Get Started
If you would like to help influence IBM to remove the DDS requirement from RPG OA, there's now a petition feature that you can access at www.IBMiOA.com. You can also add your own suggestions.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online