Frequently Asked Questions About the Redvers Cobol XML Interface

Why have you written the interface in COBOL?

We’ve taken the unusual step of writing and delivering this product in COBOL source code subroutines because we understand how important it is to have a product that is easily integrated with existing applications. If you need a product to interface XML with COBOL applications then you must have COBOL programs and a COBOL compiler already. Another advantage is that people using the product will already be familiar with the terminology, characteristics and capabilities of COBOL based programs.

What are the technical limitations?

As the product is written and compiled as a COBOL program the limitations are the same as those placed on the calling application. Therefore, if your application uses a 16MB copybook layout with 5,000 fields on it, each requiring a 500 character XML tag, our subroutines can process it. In order to make the most efficient use of machine resources, several parameter variables (referred to in the user guides as User Maintained Variables) are defaulted to fairly modest values but they may be increased or decreased according to requirements.

What are the benchmark statistics?

A generation rate of 1.79 kilobytes per millisecond and a parsing rate of 1.35 kilobytes per millisecond were obtained during a test run at the IBM Innovation Centre at Hursley, UK. The machine used was an IBM xSeries running 500 MHz Power3 processors.

Most applications will require I-O external to the interface in order to collect data for conversion to XML or to update COBOL based files/database from the XML input. In general, the fact that almost no I-O is performed by the interface, means that it will keep pace with the speed of any calling application.

Will the parser validate the incoming XML document?

For many years the parser interface programs have issued an error message when an input XML document is not well-formed (contains syntax errors). In addition to this function, the next release (2.7) due out in 2008, will provide an option for full W3C schema validation, to ensure XML documents are not only well-formed but also valid. To ensure optimal processing speeds, validation will be carried out as the data is transferred from XML to COBOL format, thus avoiding the overhead of reading and interpreting the XML data more than once.

If you would like further details on this development, please contact us using our Contact Us web page.

What is the difference between the batch and message level versions?

The batch version reads or writes an XML document directly from/to an external file using its own FD’s and internal file names of RCXMLIN or RCXMLOUT respectively.

The message version also runs as part of a batch application but it passes the XML document to and from the calling program in linkage. This approach means that the calling application must read or write the XML document but it provides the opportunity for the processing of XML documents coming from, or going to, a message queue utility such as MQ Series.

How can I process arrays with two or more dimensions?

Our user guides state that only single dimensional arrays are permitted in the COBOL Record Definition (CRD). This does not mean that an infinite number of dimensions cannot be generated or parsed by the interface. The CRD merely contains the fields/elements that are transferred in a single call to the interface. When processing multiple occurrences of repeating data the application logic needs to make a call to the interface for each occurrence of the repeated fields/elements.

Using population statistics as an example, the lowest level dimension could be an individual living at an address. It would be unwise to assume that all addresses in the entire world hold less than a specific number of occupants and that all towns have less than a specific number of addresses. Therefore the CRD is written with a single occurrence of an individual’s details at a single address, rather than using multidimensional arrays with specific numbers in the OCCURS clause. Separate calls to the interface would then be made for each individual at the first address. When all individuals have been processed, the logic moves on to the first individual in the next address and processing repeats for each individual at this new address. The logic would continue for every address in a town until the next town details are passed to the interface as processing proceeds up the data hierarchy.

Our advice is that multiple calls should be used in place of multiple occurrences in all cases where the maximum number of occurrences is not absolutely certain. Remember, XML has no structural limit to the number of times elements may appear in a document. Also, this approach relieves the application of having to handle explicit table limits and incurs minimum storage requirements.

Can a CRD be automatically generated from an XML schema or DTD?

Redvers Consulting now offers two free program tools called RCSCHCRD and RCDTDCRD. These tools create a base CRD from the information held in a schema or DTD respectively. In keeping with our other tools, these are written in open source COBOL and are available for download from the Partners area of our web site.

You haven’t answered the question I had in mind.

If your question isn’t listed above please use our Contact Us page to ask any questions you may have and we will provide an answer as soon as possible.

Order your free trial here...