Problem:

If you are generating a XML document using the Net Express 4.0 or later COBOL XML extensions and if your XML document becomes very big, you will notice that while the document is being generated the performance is good, but when it comes to the last WRITE XML-stream and the file is CLOSED, it can take quite a long time depending on how big the document is and on how much memory the machine has.

Resolution:

Our XML extensions use a DOM-based parser (Document Object Model). A DOM-based parser, as supposed to an event-based parser, instead of events being fired, a tree is built up which describes the document and which can then be traversed by methods which access the nodes of the tree.

So when you create an XML with our COBOL extensions, a tree is being built in memory and, therefore, the tree can not be flushed to disk until it is completed because when you write a node, you also have to write all the sub-nodes.

This ensures that you create a proper XML document and also that the XML document is validated against its Schema or DTD.

If you have a performance problem because the XML documents can be very big, one suggestion would be to launch the processing of the database and XML generation in a different process. This would allow your users to carry on working in other things. Once the process is finished you could inform the user with a message box, for example.

Also, you could try writing the XML document to a buffer in memory instead of directly to a file defining in the select

                SELECT myXML assign to address of mybuffer

This should make the CLOSE faster, but then you would have to write the buffer to disk... and it would take twice the amount of memory.

Alternatively, you could skip the validations all together by generating the XML document "by hand".  There is nothing stopping you from creating a line sequential text file that writes things like <mytag> value </mytag>. The big disadvantage is that if you want to ensure that the document is a proper XML file, you would have to parse it separately. In this case using an event-base parser may be faster, we support the IBM implementation of XML PARSE.