Life After DDS

Do you ever sit back and think to yourself how much things have changed in the last few years, particularly in the area of IT? So many new devices and services are available today that were almost in the realm of science fiction only 10 years or so ago. And yet as far as our favorite platform is concerned, we’re still using the same old methods for describing device files that we were more than 20 years ago. Our system’s capability to externally describe device files was a major breakthrough in its day and is still a source of strength. But things are changing.

As far as creating database files is concerned, the future is clear. DDS is being replaced by SQL and DDL. SQL is an industry standard and is an excellent fit for the platform.

But what does the future hold for things like printer files? In many companies, report files—in the sense that we have traditionally understood them—have all but disappeared. Reporting now comes in the form of Web pages and spreadsheets. Who knows what form it will take in the future—holograms perhaps? But one thing is for sure, whatever it is, DDS is not the vehicle to take us there. It’s really a very poor “language” on which to base future development.

So how are we to cope with all the changes that technology brings to us? So far we’ve managed, but it has come courtesy of technology advances from ISVs. But each of these ISVs has had to keep reinventing the wheel because there has been no single central standard to which they could all work. It’s time for that that situation to change before it gets any worse.

We believe that we need a new standard for describing device files—one that is sufficiently flexible to take us into the future while still supporting the devices such as printer files and display files that we’ve all grown up with. Turns out that there is such a standard. It’s known as the Open Access definition standard (OAMOS) and it even has its own website

A Little History

Before we go into further detail, a little history is perhaps in order. Turns out we are not the first people to have thought that a new standard for external definitions was a good idea. A friend of ours by the name of Pascal Polverini came up with the idea many years ago. There may of course have been others too, but Polverini is the only one we know about.

Polverini began his work in the early 2000s with the idea of developing an XML-based format that could encompass everything that DDS currently defines for printer files, display files and, for good measure physical and logical files as well. By using XML as the base, he felt that such a standard could evolve over time to encompass any future device types and characteristics that emerged. The proof of this perspective was soon apparent as Apple, Microsoft and others began to use XML to describe spreadsheets, presentations and other documents.

While Polverini was able to utilize his tooling to good effect within his own work, it was not until the emergence of Open Access and Polverini going to work for looksoftware that anybody else began to take notice. With encouragement from looksoftware and IBM’s Steve Will among others, Polverini began the process of establishing OAMOS as a formal standard. We were among a number of industry experts that were recruited to help develop the standard. Subsequently looksoftware recognized the value of using an open XML-based standard, and although they already had an in-house definition methodology, decided to adopt OAMOS as the base for their Open Access product openlook.

You might be wondering at this time why such additional definitions were needed. After all, isn’t that what RPG Open Access (OA) is all about? Doesn’t it take care of these issues? If you’ve read some of our articles on the subject of writing your own OA handlers (see “Handling Input Handlers With RPG Open Access“ and “More Flexible Open Access Input Handlers”), you might note that we have concentrated mostly on OA handlers that use data files rather than device files. Why? Because in the case of a database file, OA does indeed give the programmer pretty much all of the information needed to handle the data. OA supplies the handler with information such as variable names, data types, lengths and, of course, the values.

The New DDS?

So what else could you possibly need? Well with device files, there’s a whole lot more you need to know. For example, where on the screen or the report line is the data supposed to go? RPG knows nothing about that. All it knows is the buffer layout. Or take the case where either field A or field B is output at a given position depending on an indicator setting. RPG, and therefore OA, knows about the indicator but not what it’s used for. It also knows about the two fields but not that only one of the two will be used in any given output operation. Begin to see why additional metadata is needed? And we haven’t even touched on things like message constants and literals defined in the device file DDS.

Once OAMOS was established, we hoped that with IBM’s support it would take off and soon become the “new DDS.” But to date this hasn’t happened. In some respects, this isn’t surprising given that the standard was XML based whereas some Open Access vendors had opted to use JSON for their internal data definitions because of its direct applicability to the browser interfaces they were creating. Switching to an XML-based standard clearly would present them with many problems with few, if any, obvious advantages.

Subsequently, the OAMOS team updated the standard to address these issues and, as you’ll see if you visit the website, the current version now supports both XML and JSON definitions. The revised standard has gained some support within the general ISV community and we understand that requests have been made via the ISV Advisory Council to have the RPG compiler updated to accept an OAMOS specification as the external definition for a device file. We think that idea has tremendous potential. Combined with an OA handler it could provide the foundation for RPG to handle almost any kind of “device” from spreadsheets to Web services to CSVs to graphs to ... holograms?

What’s Next?

So what needs to happen next? While IBM has supported the basic effort to establish a standard, it hasn’t enhanced any of its existing tooling to utilize it—and this is critical. It doesn’t matter how many ISVs adopt the standard; if IBM doesn’t support it in a direct and practical sense, it will never replace DDS.

Another reason why IBM needs to support this effort concerns the very future of the platform. Free-form RPG support has made a huge difference in the acceptability of the language to young programmers. But we need these folk to be able to embrace all aspects of the system in ways that make sense to them. They can already use DDL for table definitions. Free-form RPG looks familiar, and they embrace the power that it offers. So are we really going to force them to go back to the time of the punch card to code DDS for any display and printer files that they need? It makes no sense.

What else could come out of such a change? For one thing, it would certainly make it simpler and more cost-effective for ISVs and open-source vendors to develop new device handlers. Take printer files as an example. Suppose that you wanted to develop a device handler that would work as a printer file in an RPG program. You would have to invest considerable time and money to write a parser for the PRTF DDS. But what if a DDS parser that generated OAMOS XML was already available as open source? That would significantly change the picture. It would massively reduce the costs of developing such handlers in the future.

So, in addition to IBM stepping up to the plate, we need one of the ISVs that currently have DDS parsing tools to make some of their technology available to the community. Once such plans are in place, we can begin to take the OAMOS standard seriously as the future of DDS.

A Ton of Potential

There is so much potential here and frankly, right now, so much energy and resources being wasted by the multitude of ISVs that are all developing their own proprietary technology. In the age of open source, this makes no sense and ultimately benefits no one.

Think of some of the other benefits of such a strategy:

  • DDS limitations disappear—things like the maximum variable size of 32K, limit of 9,999 rows in a subfile, limited data type support (no images, for example), etc.
  • All existing RPG data types could be integrated (Integer, Boolean, etc.) along with direct support for arrays, DS and anything else you can think of.
  • It could provide an alternative to PCML that allows full description of all parameter data types.
  • You won’t have size or layout limits for “screens” or “documents”—for example, side-by-side grids could be defined.
  • Any and all GUI controls can be integrated.
  • Long names can be used for formats and fields.

And this is just a first cut at the list. We haven’t even begun to think really hard about the possibilities.

What do you think? Could we use a new extensible standard that goes beyond DDS?

We think so, and we’d like to hear your views. And if you agree with us, tell IBM!

One last note: The folks behind OAMOS are currently running a survey to see what developers think about enabling the RPG compiler to use such a definition as an alternative to DDS-based files. You can find the link on their home page Go and vote, and while you’re there take a look at the standard definition. You can also read a short article on the latest changes to the standard.

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



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