0

XML messages with the special characters(Ý,¨) , which are actually XML valid characters are being treated as invalid characters for the default encoding that is assigned to a message, when not specified. We tried to make this work by specifically adding the encoding type to the top of the message. We used the UTF-8 encoding. So by adding "" to the very beginning of the XML message, the characters should ideally become valid characters.

To add the XML declaration, we used WITH ENCODING 1208 while doing an XML GENERATE to generate the declaration in the xml document.

  • Default Encoding option: IBM-1140
  • The XML document is generated inside an alphanumeric data item.
  • XMLPARSE (XMLSS) compiler option is in effect

We then put the generated XML(with declaration) into a CICS container DFHWS-BODY. But CICS then attaches the Envelope to the very beginning of the xml document passed from the Cobol program.

So, the question here is how can we attach the XML declaration(in CICS) to the very beginning of the xml document for the outside environment to identify the encoding option and convert the special characters in the correct format?

kushwah_a
  • 135
  • 2
  • 9

2 Answers2

0

You're generating the XML in your program? That's an interesting approach. Normally, for a CICS web service (as opposed to a CICS web support program) CICS generates the XML from the data structure you supply in the DFHWS-BODY container as per the WSBIND file. Perhaps you chose to use the XML-ONLY parameter of DFHWS2LS.

A quick search indicates you've been trying to solve this problem in various ways. You might want to try the CODEPAGE(1208) compile option and, if necessary, the NOSQLCCSID compile option.

In any case, if you want to modify the response after CICS is done doing its processing of the response, use a transport handler program. Declare the transport handler in your pipeline configuration file. Keeping in mind your transport handler will be called for both requests and responses, code your transport handler to check to see if it is processing a response and only then add your XML declaration to the contents of the appropriate container (DFHRESPONSE I believe). You can determine if the current function is a response by examining the contents of the container named DFHFUNCTION. The IBM-supplied copybook DFHPIUCO will provide you with some constants you will require.

You're going to be modifying containers that CICS normally handles for you. If you make a mistake, you might find yourself with an interesting abend and an unhappy CICS Systems Programmer. Take extra time to debug your transport handler thoroughly so you don't end up with a production problem when some edge case occurs.

Pipeline configuration files, transport handlers, etc. are all documented in the CICS Knowledge Center.

IBM supplies an example handler program (SNIFFER) in the redbook SG247206 Implementing CICS Web Services Published 10 October 2007. There's a more recent redbook by the same name but it doesn't seem to have the handler program source code included.

cschneid
  • 10,237
  • 1
  • 28
  • 39
0

It is possible to write your own handler program, and add that handler program to the pipeline configuration xml as a service handler. Now when your program hands the DFHWS-BODY container back to the terminal SOAP handler, it will construct the response SOAP message (including, as you noticed, the SOAP envelope) in the DFHRESPONSE container. All service handlers that are started after the termination of the terminal SOAP handler (check the contents of the DFHFUNCTION container to determine the phase of the request) will be able to alter that container, if they wish, and could add an XML declaration in the beginning of the response. Keep an eye on codepage conversions when constructing your new response container, as an error is easily made there...

Remko
  • 359
  • 2
  • 8