NAT8312 Error during XML parser processing, reason 5

[Werner_Bredenhann]

I am trying, for the first time, to call a Web Service using Natural on a mainframe (Natural 4.2.5).

The reponse from the Web Service is successful, but after extracting the response from the SOAP Envelope, I get the error above when trying to use the statement PARSE XML:

NAT8312 Error during XML parser processing, reason 5
Unsupported encoding is used

After getting the response, we decode it into UTF-8, and succesfully extract it from the SOAP envelope. It is 100% readable when writing the response to the screen.

The extracted response from the SOPA Envelope looks like:

falsefalsefalse

Can anyone help?

[Steve_Robinson]

I haven’t tried it yet on the mainframe, but it works just fine on my PC.

PARSE XML #A INTO PATH #B
PRINT #B
END-PARSE
END

Where #A is your XML (above) but with at the end of the string

what is your exact PARSE statement?

steve

[Werner_Bredenhann]

Hi Steve

The PARSE statement looks like (as generated by XML Toolkit):

PARSE XML #XML_INPUT INTO PATH #XML_PATH NAME #XML_NAME VALUE #XML_VALUE

The values of these variables just before execution of the PARSE XML statement:

#XML_INPUT: false
falsefalse
#XML_PATH:
#XML_NAME:
#XML_VALUE:

Werner

[Werner_Bredenhann]

Sorry, for some reason, not everything I type into the msg gets posted:

So I’l double space it to see if it works:

#XML_INPUT: false
falsefalse

[Werner_Bredenhann]

Still not. Ok the is supposed to be:

“<?" XML VERSION='1.0' "?>”

Remove all the double quotes and string it together

[Douglas_Kelly]

is there an encoding= clause in that clause that the forum software keeps zapping (it should be in all lower case too) ?

You indicate that you are running on the mainframe and have decoded the result to UTF-8. If you did, you would not be able to read the output on the mainframe - the mainframe uses EBCDIC code pages (such as CP1040), not UTF-8.

Verify your default code page (display *CODEPAGE) and make sure the encoding= matches what is in the string to be parsed. See the documentation on code pages used (http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat426mf/unicode/uni-language.htm#uni-language-parsexml and http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat426mf/pg/pg_xml.htm#pg_xml_avail_parse):

The encoding of the document to parse is checked automatically.

A check for a BOM (Byte Order Mark), which marks the document’s encoding, is done.

If no BOM is found, a check for ASCII, EBCDIC, or UTF-16 (BE or LE: big endian or little endian) is done.

If an EBCDIC or ASCII encoding is identified, a search for an encoding processing instruction is performed.

If no encoding can be identified, an adequate error message is issued and the parse process is terminated. Internally, the parser works with UTF-16BE, so the document to parse is always converted to this encoding before it is passed to the EXPAT parser.

If an encoding PI (Processing Instruction) is found, the following defaults apply:

for ASCII, UTF-8 is assumed as encoding

for EBCDIC, the Natural default code page (see system variable *CODEPAGE) is assumed as encoding

[Windpomp]

A year on and I ran right into the same issue as Werner.

My resolve.

I stripped only the to from the returned page into #XML-RESP. If only this page is PARSEd, the NAT8312/5 occurs.

add to beginning of #XML-RESP.

Problem solved.

[Gil_Wildin]

Hello I am using a REQUEST DOCUMENT statement and a PARSE XML statement and getting the same error message. When I hard code a valid
XML document into my #PAGE member, the PARSE XML works fine, so I believe the problem lies with the REQUEST DOCUMENT statement.
I am trying to request a valid XML document from a server. The document should be ASCII, right? I get a 200 return code, so the http: request
is ok. Here are some snippets from my code:
ASSIGN #FROM = ‘https://dpdev1.dp.utexas.edu/test/pli/utl/sample.xml’
REQUEST DOCUMENT FROM #FROM
RETURN
HEADER ‘content-type’ #HEADER
PAGE #PAGE ENCODED FOR TYPE ‘text/html’
CODEPAGE ‘ISO-8859-1’
RESPONSE #RC
GIVING #RTERR
PRINT #HEADER
/ ‘'(79)
PRINT #PAGE
/ '’(79)
…

Here is some of the output:
#RC: 200
text/html

---

?ÇÈ_%???ÇÁ/À???ÈÑÈ%Á?ñ>Ã?Ê_/ÈÑ?>?èÁÄÇ>?%?Å?ëÁÊÎÑÄÁË???íè?áñà?<?Å?>??ÈÑ ??????????ÇÑÀÑ>Å?¦/Î/ËÄÊÑøÈ?ÃÊ?_??%À?ÂÊ?ÏËÁÊË??????????????????ÃÍ>ÄÈÑ?>?>ÁÏïÑ>? Ê?/øøîÁÊËÑ?>??????????????????????????????ïÑ>À?ÏË?_/ÄÇÑ>ÁË?>ÁÁÀ?È??%Â/Ê?È??øÊÑ> ÀÁÌ|Ã??ïÑ>??????????#??????????????????????????????????ÀÑËø%/è??%Â/Ê???Ã/%ËÁ??
???ÀÑËø%/è??%Â/Ê???ÈÊÍÁ???????????????????????????'??????????????? ??????????????ÇÁ%øïÑ>À?Ï???ÏÑ>À?Ï??øÁ>?>ÁÏø/ÅÁ??ÇÁ%ø???È??%Â/Ê?ÁË?ËÄÊ?%%Â/ÊË?`
???ÇÁ%øïÑ>À?Ï???ÏÑ>À?Ï??øÁ>?>ÁÏø/ÅÁ??ÇÁ%ø???È??%Â/Ê?>??ËÄÊ?%%
…

It looks like an ASCII/EBCDIC problem, but I am at a loss to figure it out. Thanks for your help in advance!

Gil

[Douglas_Kelly]

You can see the returned document if you use the MOVE ENCODED statement to turn the ASCII into EBCDIC. As part of the REQUEST statement, include

    NAME 'Content-Type'      VALUE #DOC-CHARSET

Examine the #DOC-CHARSET to find what the character set used is

  IF #I > 0
  EXAMINE #DOC-CHARSET FOR FULL 'charset=' GIVING POSITION #I
  IF #I > 0
    ADD 8 TO #I
    SEPARATE SUBSTRING(#DOC-CHARSET,#I)
      LEFT INTO #DOC-CHARSET IGNORE
      WITH DELIMITERS ' ;/&?'
  ELSE
    MOVE 'ISO-8859-1' TO #DOC-CHARSET
  END-IF
  MOVE ENCODED #XML CODEPAGE #DOC-CHARSET TO #DISPLAY-DOC

You can then view #DISPLAY-DOC on the mainframe terminal.
There should be an XML prolog with an encoding parameter (see other replies here, its hard to post). Try removing the CODEPAGE clause - you may be requesting the document to be translated into something but that doesn’t match the XML prolog encoding clause, so the PARSE fails.

If there is no prolog specifying the encoding, Natural assumes its own codepage applies. In this case, use the Content-Type encoding and the MOVE ENCODED to translate it first.

[Gil_Wildin]

Wow, thank you, Douglas, it worked beautifully. It’s great to have such sharp people on this forum. thanks, again.