Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Cobol XML Parse from seq.fileFiles
- Thread starter mole123
- Start date
fredericofonseca
IS-IT--Management
cobol vendor, os and version of both os and cobol please. as there might be limits/ways of doing things differently depending on those.
but base process is to read each record from the input file, string them into a single variable and then using that variable to as input to the parse statement.
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
but base process is to read each record from the input file, string them into a single variable and then using that variable to as input to the parse statement.
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
- Thread starter
- #3
Don't remember the version, but it's the latest on the 3090 host mainframe!
Your surguestion is exactly the way I can't do it because of the number of statement in the XML-file! There can be millions of rows in the input-XML dataset!!!
So: what to do???
Your surguestion is exactly the way I can't do it because of the number of statement in the XML-file! There can be millions of rows in the input-XML dataset!!!
So: what to do???
Some years ago, I tried XML PARSE on IBM iSeries.
The XML document could be either in one field or in an stream file (in case of iSeries stored in IFS)
The syntax is
where
see the example in my earlier thread:
For mainframe specific questions try the IBM manuals.
The XML document could be either in one field or in an stream file (in case of iSeries stored in IFS)
The syntax is
Code:
XML PARSE FILE-STREAM xml-id PROCESSING PROCEDURE xml-handler
Code:
1 xml-id pic x(27) value '/home/user1/xmlsampldoc.xml'.For mainframe specific questions try the IBM manuals.
- Thread starter
- #5
By the way, my cobol version is: Enterprise COBOL for z/OS V3.4
After reading the manual I first found the following:
"The XML PARSE statement supports XML files encoded in Unicode UTF-16 or any of several single-byte EBCDIC code pages. Support is not provided for ASCII code pages."
But then sadly this:
"If the XML document that you want to parse is held in a file, use ordinary COBOL facilities to place the document into a data item in your program:"
So it seems I have to code my own Parse routine!
But thanks for your help on the matter!!!
Regards
After reading the manual I first found the following:
"The XML PARSE statement supports XML files encoded in Unicode UTF-16 or any of several single-byte EBCDIC code pages. Support is not provided for ASCII code pages."
But then sadly this:
"If the XML document that you want to parse is held in a file, use ordinary COBOL facilities to place the document into a data item in your program:"
So it seems I have to code my own Parse routine!
But thanks for your help on the matter!!!
Regards
I found out, that I posted my question in 2005 in this forum too 
Maybe Enterprise COBOL's XML PARSE statement doesn't have the FILE-STREAM keyword so you need to read the file into a working-storage field before parsing.
Maybe Enterprise COBOL's XML PARSE statement doesn't have the FILE-STREAM keyword so you need to read the file into a working-storage field before parsing.
fredericofonseca
IS-IT--Management
what type of info are you parsing? and fact that there are millions of rows on the file does not mean it wont fit on a single ws variable (which has a limit of 134,217,727 bytes).
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
- Thread starter
- #8
Type of data??? What do you mean?
Rows containing payments and that kind....
I can not build a solution that doesn't work if the amount of data exeeds 134,217,727 bytes of XML.
I'm currently trying to find out weather or not DFSORT or maybe FILAID can convert XML files to a more traditional formattet dataset that I then can use as input in my cobol-program!
If any of you know anything in that direction, please let me know!
Thanks again for all your responses!!!
Regards!
Rows containing payments and that kind....
I can not build a solution that doesn't work if the amount of data exeeds 134,217,727 bytes of XML.
I'm currently trying to find out weather or not DFSORT or maybe FILAID can convert XML files to a more traditional formattet dataset that I then can use as input in my cobol-program!
If any of you know anything in that direction, please let me know!
Thanks again for all your responses!!!
Regards!
fredericofonseca
IS-IT--Management
mole
When I asked what type of data you are processing is to see if there would be other means of doing it.
If the xml data is always the same type of data on each file, e.g. number of XML ELEMENTS are always the same and always of the same type, even if there are different "record types" (to use a COBOL terminology), then its feasible to do it.
Also if you are using DB2 v8 or greater, and again depending on the type of information on the xml file, it might be possible for you to use DB2 to do the parsing instead, and pass the info back to you on DB2 table format.
if you can supply the XML Schema (if its not confidencial) then I(we) might be able to give you some more pointers.
Without it its a bit harder, as not XML files are not always REAL XML files, even if they look like it (and i speak based on real experience with badly designed XML files from customers)
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
When I asked what type of data you are processing is to see if there would be other means of doing it.
If the xml data is always the same type of data on each file, e.g. number of XML ELEMENTS are always the same and always of the same type, even if there are different "record types" (to use a COBOL terminology), then its feasible to do it.
Also if you are using DB2 v8 or greater, and again depending on the type of information on the xml file, it might be possible for you to use DB2 to do the parsing instead, and pass the info back to you on DB2 table format.
if you can supply the XML Schema (if its not confidencial) then I(we) might be able to give you some more pointers.
Without it its a bit harder, as not XML files are not always REAL XML files, even if they look like it (and i speak based on real experience with badly designed XML files from customers)
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
Mole,
the XML PARSE statement on the mainframe is used to take one long chunk of XML and using the PROCESSING PROCEDURE XXX-PARSE option, performs another section (XXX-PARSE) to obtain the value of the XML tagged fields and place them into variables in your program.
What (I think) you are describing is a sequential input file that contains lines of XML data. If this is the case, you could read each line of the file and run a XML PARSE statement against it and obtain the data you require. Alternative, you could unstring each line of the file using '<' or '>' in order to get your data out.
I've got an example of the PARSE statement on the mainframe if it would be of any help.
Hope this helps.
Marc
the XML PARSE statement on the mainframe is used to take one long chunk of XML and using the PROCESSING PROCEDURE XXX-PARSE option, performs another section (XXX-PARSE) to obtain the value of the XML tagged fields and place them into variables in your program.
What (I think) you are describing is a sequential input file that contains lines of XML data. If this is the case, you could read each line of the file and run a XML PARSE statement against it and obtain the data you require. Alternative, you could unstring each line of the file using '<' or '>' in order to get your data out.
I've got an example of the PARSE statement on the mainframe if it would be of any help.
Hope this helps.
Marc
- Status
Similar threads
- Locked
- Question