IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
No replies
403 Posts

Pinned topic XML PARSE translate CrLf to NewLine

‏2012-10-25T07:21:14Z |
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)
Updated on 2012-10-25T19:56:40Z at 2012-10-25T19:56:40Z by SystemAdmin
  • brataj
    40 Posts

    Re: XML PARSE translate CrLf to NewLine

    ‏2012-10-25T15:16:47Z  in response to SystemAdmin
    The 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
      403 Posts

      Re: XML PARSE translate CrLf to NewLine

      ‏2012-10-25T19:56:40Z  in response to brataj
      Thanks 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.