Skip to main content

What is the lifespan of the XML Extensions cache?  I presume that it is for the life of the rununit but I don't see that in the Users Guide. Experienced an issue where we changed the number of occurs in a record that is being exported/imported to XML and multiple users began experiencing errors due to XML data in the OCCURS portion of the record not conforming to the record image.  thought we would be ok to change the program as it is dynamically called (i.e. CALL'ed and CANCEL'ed at each invocation) but we still had the error for users that previously executed either the import or export functions.  I presume this is due to data in cache no longer matching record image in recompiled program.  We run with the default of cache enabled (according to Users Guide).  For efficiency's sake, we don't want to disable caching, but need to figure out where we need to insert a FLUSH of the cache to ensure that if the called program is recompiled, the process won't prematurely terminate with the type of data issues we have seen. 

What is the lifespan of the XML Extensions cache?  I presume that it is for the life of the rununit but I don't see that in the Users Guide. Experienced an issue where we changed the number of occurs in a record that is being exported/imported to XML and multiple users began experiencing errors due to XML data in the OCCURS portion of the record not conforming to the record image.  thought we would be ok to change the program as it is dynamically called (i.e. CALL'ed and CANCEL'ed at each invocation) but we still had the error for users that previously executed either the import or export functions.  I presume this is due to data in cache no longer matching record image in recompiled program.  We run with the default of cache enabled (according to Users Guide).  For efficiency's sake, we don't want to disable caching, but need to figure out where we need to insert a FLUSH of the cache to ensure that if the called program is recompiled, the process won't prematurely terminate with the type of data issues we have seen. 

Hi, David!  It has been a while...

Do I understand that you are recompiling the program during the runtime of a program?  If so, why?

You are correct that XML cache runs the duration of the run unit, and can be flushed as necessary.  I have seen very few situations where the cache is an issue.

Can you move up to the 20000 foot level and describe what the situation is that has you apparently recompiling on the fly?

Best regards,
Tom

What is the lifespan of the XML Extensions cache?  I presume that it is for the life of the rununit but I don't see that in the Users Guide. Experienced an issue where we changed the number of occurs in a record that is being exported/imported to XML and multiple users began experiencing errors due to XML data in the OCCURS portion of the record not conforming to the record image.  thought we would be ok to change the program as it is dynamically called (i.e. CALL'ed and CANCEL'ed at each invocation) but we still had the error for users that previously executed either the import or export functions.  I presume this is due to data in cache no longer matching record image in recompiled program.  We run with the default of cache enabled (according to Users Guide).  For efficiency's sake, we don't want to disable caching, but need to figure out where we need to insert a FLUSH of the cache to ensure that if the called program is recompiled, the process won't prematurely terminate with the type of data issues we have seen. 

Tom, nice to hear from you. Hope all is well with you.

First question: "Why?" We were recompiling the program to correct an error. Thought it would have no impact as the program is called dynamically and expected new requests for the program to get the latest (corrected) version (which it did) but for any session where the recompiled version was invoked we started getting "squirrelly" results with the import/export of the xml documents.

Second question: "20000 foot level" - menu program A, calls UI program B, which is then used to invoke work program C multiple times (typically several hundred per user per day) for each unit of work required, and program C calls program D, which exports an xml document that gets posted to a web process and program C subsequently imports the response from the web process. We recompiled program D to increase the OCCURS for a table in the xml document that gets exported/imported. We started getting unexplainably large gobbledygook in some of the table entries of the expanded table in import/export record for users that had previously invoked program C. The run unit is "owned" by program A, and I suspect that the cache will not be cleared until program A is exited. Does this sound correct to you? Or am I completely misunderstanding how XML extensions works here?

I think we need to keep caching in place for performance reasons. If I am not completely wrong in my understanding, I am hoping that we can insert a flush of the cache either at the beginning or end of program B, so that if we have to modify program C during operations, we can at least have all the users back up to menu program A and then re-enter UI program B, to ensure that subsequent calls to program D will start with a "clean" cache.

Best regards,
David S.

What is the lifespan of the XML Extensions cache?  I presume that it is for the life of the rununit but I don't see that in the Users Guide. Experienced an issue where we changed the number of occurs in a record that is being exported/imported to XML and multiple users began experiencing errors due to XML data in the OCCURS portion of the record not conforming to the record image.  thought we would be ok to change the program as it is dynamically called (i.e. CALL'ed and CANCEL'ed at each invocation) but we still had the error for users that previously executed either the import or export functions.  I presume this is due to data in cache no longer matching record image in recompiled program.  We run with the default of cache enabled (according to Users Guide).  For efficiency's sake, we don't want to disable caching, but need to figure out where we need to insert a FLUSH of the cache to ensure that if the called program is recompiled, the process won't prematurely terminate with the type of data issues we have seen. 

David,

Sorry I have taken so long to reply.  I seem, somehow, to have modified my notification options.

My guess is that the model document for the old program was still in the cache.  If you remember back to the earlier versions of XML Extensions, you had to create model files using a utility and arduously keep them together with the COBOL object file.  If you changed the program in a way that changed the data layout, you had to rebuild the model files.

Later versions of XML Extensions build the model document at runtime using the XML symbol table embedded in the COBOL object file.  When an export/import is executed, the model document (no longer a file) is created and kept in the cache for later reuse.

According to your description, I think that the model document would still be in the cache even though the COBOL object program is reloaded.

A cache flush is not a wildly bad idea.  However, there are ways to accommodate an input document (presumably from a third party which you do not control) that has a large number of repeating items.  This would free you from the need to recompile...

Tom

What is the lifespan of the XML Extensions cache?  I presume that it is for the life of the rununit but I don't see that in the Users Guide. Experienced an issue where we changed the number of occurs in a record that is being exported/imported to XML and multiple users began experiencing errors due to XML data in the OCCURS portion of the record not conforming to the record image.  thought we would be ok to change the program as it is dynamically called (i.e. CALL'ed and CANCEL'ed at each invocation) but we still had the error for users that previously executed either the import or export functions.  I presume this is due to data in cache no longer matching record image in recompiled program.  We run with the default of cache enabled (according to Users Guide).  For efficiency's sake, we don't want to disable caching, but need to figure out where we need to insert a FLUSH of the cache to ensure that if the called program is recompiled, the process won't prematurely terminate with the type of data issues we have seen. 

Tom,

no need to apologize. I have no doubt you are busy.

Thanks for the explanation regarding the model document. It helps to know the correct terminology.

I would be interested in hearing more about alternate ways to accommodate an input document with large numbers of repeating items. In our case it is not that there are so many of the repeating items but that the number varies with each unique situation and we are still learning what to expect. We were previously expecting no more than 20 but found that we were receiving more than that (22), and so I doubled the size of the table portion that receives those from 20 to 40. That was the recompile that triggered issues leading to this thread.

As always your experience and insights are highly appreciated. Thank you for your time and attention.

What is the lifespan of the XML Extensions cache?  I presume that it is for the life of the rununit but I don't see that in the Users Guide. Experienced an issue where we changed the number of occurs in a record that is being exported/imported to XML and multiple users began experiencing errors due to XML data in the OCCURS portion of the record not conforming to the record image.  thought we would be ok to change the program as it is dynamically called (i.e. CALL'ed and CANCEL'ed at each invocation) but we still had the error for users that previously executed either the import or export functions.  I presume this is due to data in cache no longer matching record image in recompiled program.  We run with the default of cache enabled (according to Users Guide).  For efficiency's sake, we don't want to disable caching, but need to figure out where we need to insert a FLUSH of the cache to ensure that if the called program is recompiled, the process won't prematurely terminate with the type of data issues we have seen. 

David,

The basic technique is to use XML SET XSL-PARAMETERS (and XML CLEAR XSL-PARAMETERS) to control the XSL.  Then you can use XML IMPORT FILE in a loop to retrieve 'chunks' of the input document.

XSL transforms define parameters using the <xsl:param> instruction as an immediate child of the <xsl:stylesheet> instruction.  It is these parameters that are controlled with the XML SET XSL-PARAMETERS statement, which sets up values to pass to the XSLT on a subsequent XML IMPORT/EXPORT FILE/TEXT.  Note that since these values are 'remembered', it is good programming hygiene to use XML CLEAR XSL-PARAMETERS after the XML IMPORT FILE that uses the parameters.

I have employed a few different techniques over the years, but the one that I most often employ is to use a single stylesheet with one parameter as a 'command' and other parameters as needed by the various 'commands'.  In this technique I typically have two commands: the initial call that returns the invariant/header information and a count of the detail elements, and a second call (in a loop) that returns one or more of the detail elements.  Because all of the XML documents are cached, the overhead of loading XML documents from disk is minimized.

Please feel free to ask questions on this thread.  I have looked for examples which I once had, but unfortunately those have disappeared in the mists of time!

Terms & ConditionsAccessibility statement