Report an error when 'GENERATED_XML_DATA' is passed not supported hex values

We have assessed this requirement. We have no current plans for this to be implemented and so this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

We also face problems in this area. Our developers complaint that they receive a parser error on the java side.

Caused by: javax.xml.soap.SOAPException: com.ctc.wstx.exc.
WstxUnexpectedCharException:
Illegal character ((CTRL-CHAR, code 26)) at \[row,col {unknown-
source}]: \[1,5608468]

The analysis on our end have led to unprintable characters - in this
case a x'35' contained in the application data.

According to the specification : http://www.w3.org/TR/REC-xml/#charsets

this is not allowed.

I read the CICS Webservice manual and found the following information
about encoding limitations :
https://www-01.ibm.com/support/knowledgecenter/SSGMCP_5.2.0/com.ibm.
cics.ts.webservices.doc/concepts/applications/dfhws_limitations.html

However i think CICS should stick to the W3 specification.

To circumvent the issue we wrote a transport message handler that scans
the DFHRESPONSE container for illegal
characters and blanks them out. It's certainly not the best way to do
it.

It would be logical to do it where CICS already encodes the XML entities
such as < > &.

We migrate from Corba to Webservice and in Corba this characters were allowed.

This is a candidate for a future release

Data returned in a Web Service may originate from program, DB2, VSAM, MQ many places. If for some reason there is an error in a program or an earlier program placing invalid hex values in DB2 then we have a situation where we have the risk of passing non EBCDIC values back in a reply. Instead of not giving any error in these cases and pass no data we would like an error message as well.

If the content of a 'string' starts will a null-terminator then that indicates an empty string. It sounds like what's wanted for this test case is binary content, not text - many of the bit patterns represent control codes that are invalid in text fields. If a binary mapping it used instead then the data can be sent base64 encoded, and will arrive at the destination bit-fot-bit identical to how it began (including preservation of null bytes). Try using CHAR-VARYING=BINARY, or work top-down from WSDL with xsd:base64Binary defined fields.

I have attached output from a CICS trace. It contains 2 test cases.

Case 1: test case returning hex 00 til FF

Case 2: test case returning hex 40 til FF

in case 1 no data is returned in the body part

Attachment (Description): Exsample of hex values causing 'GENERATED_XML_DATA' not to returning any data at all

Please could you supply some more information as it is not clear what the problem is. It is mentioned that an 0x05 character (EBCDIC Horizontal Tab) is included in text data returned from an application. Okay, that's a valid character, it should work. What is meant by "..does not return the business data"? So is the HTTP request left dangling? Or the response data is truncated? Or is it for example that white-space characters (including tabs) are being stripped from the response message - that may be correct depending on the value of the CHAR-VARYING parameter of DFHLS2WS. In which case the solution might be to change the value of CHAR-VARYING.