Question & Answer
Question
Is there something special that could cause a WSDL to require EBCDIC encoding to be specified while others do not? Our application developer is using our processes to create a requester web service from a WSDL using DFHWS2LS. I normally have the developers remove the encoding parameter from the WSDL prior to processing. Since the WSDLs come from Windows, they usually have encoding=UTF-8, that they are instructed to remove when the file is transferred to z/OS. Even when doing this, the assistant gave this error:
DFHPI9606E The value of the XML encoding attribute must match that of the underlying file system. For example, the value "EBCDIC-CP-US" may be appropriate.
I was able to alter the WSDL to use encoding=EBCDIC-CP-US and get the assistant to work. This has not been done in the past, and I tried a WSDL of another CICS web service and was able to process it without encoding by simply having <?xml version="1.0"?> at the beginning of the WSDL.
I have a WSDL that has been previously used and does not include the encoding. I was able to use it without any alteration.
Answer
The problem with the new WSDL file was discovered to be that the file was not in a well formed state for an xml file. The entire xml file existed on a single continuous line when viewed using Notepad or Textpad. Once the xml file was well formed, it was able to be run using the DFHWS2LS assistant without message DFHPI9606E being returned.
If you have Rational Developer for z Systems (RDz) in house, it can be used to do a "cleanup" on the file.
While viewing the file in RDz, click:
"Source > Cleanup Document"
The file is then formatted to a correct xml format. If you do not have RDz then you will need to either find another tool to do the same or manually edit the xml to a well formed state.
Product Synonym
CICS/TS CICSTS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
18 July 2017
UID
dwa1384212