When using XML PARSE with encoding 277 (same result with 1140) i experience that in the content of CONTENT-CHARACTERS x'OD25' (i.e CrLf) is translated to x'15' (NewLine). I.e. in the document to be parsed there are attributes with content that contain x'OD25' but when the corresponding CONTENT-CHARACTERS are returned, I get x'15' instead. This cause problems in our application because of the fact that the COBOL programs test on x'0D25' not x'15'.
Is there a way to change this (for us) unwanted behaviour?
We are using IBM Enterprise COBOL for z/OS 4.2.0 and XMLPARSE(XMLSS)
This topic has been locked.
Pinned topic XML PARSE translate CrLf to NewLine
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-10-25T19:56:40Z at 2012-10-25T19:56:40Z by SystemAdmin
brataj 100000816340 PostsACCEPTED ANSWER
Re: XML PARSE translate CrLf to NewLine2012-10-25T15:16:47Z in response to SystemAdminThe XML System Services documentation suggests:
The z/OS XML parser will [...] normalize all line-endings to EBCDIC NL (x '15'). In general, EBCDIC is not a portable encoding so IBM does not recommend using EBCDIC for XML documents going between platforms or in the Internet.
There isn't to my knowledge a way of changing this and it's unclear to me why you would want to.
How did you end up with a file that has 0D25 line endings?
SystemAdmin 110000D4XK403 PostsACCEPTED ANSWER
Re: XML PARSE translate CrLf to NewLine2012-10-25T19:56:40Z in response to bratajThanks for your response.
We get the XML document as a "service request" through MQ from a web client application. When we do MQ-GET with convert, we get EBCDIC x'0D25'.
This is the same as we got before we started using XML (we then used a propritary tag protocol). It DOES therefore make trouble for our application that x'0D25' is translated to x'15' because we have a lot of programs that do processing based on CrLf x'0D25'.
I understand from your answer that it is probably not anything to do about this. So we will probably make a solution that replace x'15' to x'0D25' after parsing (it will be too much code to change otherwise). Not optimal solution, so if IBM will consider to parameterize this in some way we would be very happy. It would then have been a much cleaner solution on our side.