We are reading a xml documents from variable length file(LRECL=32004 i.e 32K file length).
We observed an issue when the xml content filled with 32000 bytes per line as mentioned below, and the second line starts with the
continuation of the xml tag.
?xml version='1.0' encoding='UTF-8'?><batch xmlns="www.bank.com"><batch-info id="doc_bank_20170518"><batch:sender-identifier>kbc</batch>
a) We tried using only XML-PARSE operation and processing it. It was working fine.
b) But we check validation against a data on DB2 table using SQL, when we parse the second record the Start of Element of not captured in XML-EVENT
instead it skipped the <Project-Role> and capturing as END-OF-Document at first record end byte and next record it says as START-OF-DOCUMENT and throws an "EXCEPTION"
XML-CODE = 0000798819
But when we remove the SQL statement and do the processing , it works fine.
Do we have any logging dataset to capture the XML-PARSE for each element?
Whether it has to do with any memory allocation of the program?
Please help me to resolve the issue. Meanwhile i will try to post if i found anything more
Joined: 10 May 2007 Posts: 2378 Location: Hampshire, UK
How can you have a second record when your "file" length = record length = 32004? I guess you may have meant 'data set' not 'file' and you were just confusing everyone by saying the data set length was 32k.
If you were running on a mainframe no exception was 'thrown' - nothing is 'thrown' on the msainframe in z/os - maybe z/Linux but not on the MVS part of the machine.
You have logging if you wrote it. I guess you screwed up the code change to add the sql.
Joined: 06 Jun 2008 Posts: 8553 Location: Dubuque, Iowa, USA
The issue has nothing to do with memory allocation -- period.
If you want to log your XML processing by using DISPLAY statements, you have that option. There is no logging of XML inherent in COBOL, however.
The OBVIOUS answer is that you (or whoever coded the SQL statements) screwed up the processing logic and caused the issue. Debug the added code and stop trying to blame the system for a programmer mistake.