XML and the New COBOL

Podcast
Java and XML
SQL/XML
Portals

Webcast
Java and XML
SQL/XML
Portals

Sites
COBOL
INCITS
W3C XML

Perhaps a measure of XML's importance is how it's changed industry standards. The SQL:2003 standard integrated an XML type and related functions. COBOL has been evolving with support for objects and .NET and the forthcoming standard will add XML support. Why is this significant? - Today 75% of the world's business software is COBOL code. - COBOL programs process 30 billion transactions per day. Barry Tauber of Victor Consulting is a long-time member of the committee responsible for the COBOL standard (INCITS J4). He explains the integration of XML support into the COBOL standard.

COBOL has quietly been processing XML for quite a while. Ken North was nice enough to request some input from the COBOL community. The purpose here is to elaborate some on what is going on in the COBOL world with regard to XML. What I mean by "quite a while" is since business applications began to deliver data in XML format. My first personal exposure to XML with COBOL was a 1999 effort for the insurance industry (just as the Y2K hit). The following is an overview and background information, followed by the mechanics of processing XML.

The simple explanation of this issue is that COBOL views XML as data -- simply tagged character data. Because COBOL has been particularly adept at processing character data since its inception, there seems to be a natural fit. Additionally, the hierarchical structure of XML fits quite nicely with the record layouts in COBOL. The most significant issue when blending the two had been getting the XML data ‘in’ and putting the resultant XML, if any, ‘out’. With a few extensions to the COBOL language, the ability to process XML is very easy for persons with COBOL knowledge to learn. They are already familiar with the commands and the hierarchical structure; it is just more identifiable data. The extensions are valid whether program or class (yes, COBOL has classes, interfaces, implements object orientation, etc. – different subject).

The more detailed explanation needs some background. COBOL is one of those language that is owned by no one, standardized by a committee (following a myriad set of rules), and actually implemented by vendors free to include their own ideas and extensions. One practical side effect is that partial implementations are available before a standard has been formally published. The current COBOL standard is COBOL2002; it supercedes COBOL85, the successor to COBOL74. The time lag between standards was large in relation to the rate of technology change and so there was a change of process. Beginning with COBOL85, there have been various addendums (1989) and technical reports published. These documents added features to the language, can be implemented by vendors, and were written as if they were to be included in the following standard.

Draft COBOL Standard

The XML changes to the COBOL standard will be released as a Technical Report (TR). The TR will be published by the end of 2005 or middle 2006 and it will be based on features in the 2002 standard. When it is rolled into the 2008 standard, the TR will go away. Anyone with an interest in XML and COBOL can view and comment (to me or the committee) on the current (23 Aug 2005) working draft .

As hardware and software technology advances, the COBOL language either already has the ability to handle the advances, or it does not. How it handles changes varies case-by-case. For instance, COBOL traditionally had a character user interface. When computing power could support graphics, COBOL could have defined a graphical user interface (GUI). There was considerable effort, lead by people from Digital Equipment Corporation (merged into Compaq, then Hewlett Packard), to develop a GUI for the standard. But GUIs themselves were unstable, too varied, and simply changing too fast. It seemed the more appropriate tack for COBOL to take was to enhance the ability to CALL an application that was non-COBOL, and let the marketplace develop those GUI interface applications. That is just what happened. In another technology advance, there was considerable discussion on how to incorporate relational structures. Ultimately it was decided that the database people were the best place to deal with database issues, and COBOL should simply allow an escape mechanism for whatever the database folks decided. Hence the EXEC SQL … END EXEC constructs you see in COBOL for relational data.

On the other hand, the need for additional decimal digits in processing was handled within the language simply by supporting more digits (from 18 to 31) in the decimal arithmetic. And the need for floating point handled simply by adding floating point data types. And boolean, and so on.

XML is a different animal. It is external data, but it so closely fits the COBOL model of how to deal with data that implementing XML in COBOL is natural.

Part 2 >>