I have a JAX-generated WSDL which runs as input to the subject utility fine in the RDz trial version on my laptop, but my colleague running the same WSDL input to his version of the subject utility on CICS results in some kind of error. He claims that he cannot see the program doing the conversion. Is there any way to advise him, perhaps run with a "debug profile" or some other way, in order to get any sort of diagnostic information from his system.
Sorry I am unable to attach the offending WSDL without multiple renaming, but in another case where the resulting data structure is more deeply nested, CICS works fine.
Please let me know if you need more info, thanks.
mazogi 0100003E8F109 Posts
Re: DFHWS2LS in CICS vs RDz2013-03-10T01:33:01ZThis is the accepted answer. This is the accepted answer.Depending on the version of RDz that you are running vs. the version of CICS that your colleague is running, you might be running two completely different versions of the tool. DFHWS2LS in both cases produces a log file, which will have a build ID at the top, similar to this:
Log file from: DFHWS2LS
WSBind file: C:\test\xxxxx.wsbind
WSBind/XSDBind version: NN
Mapping Level: NN
Created: 23 Jul 2012 17:53
This will tell you the dates of the versions you are running. Most likely your version is newer than your colleague's.
SystemAdmin 110000D4XK1086 Posts
Re: DFHWS2LS in CICS vs RDz2013-03-13T13:36:33ZThis is the accepted answer. This is the accepted answer.
- mazogi 0100003E8F
Regardless, FYI the issue came down to my failure to include the schema parameter setting...
<schema elementFormDefault="qualified" ...>
In the working WSDL example for some other service that my colleague provided, this parameter "elementFormDefault" was included, and he observed in the corresponding DFHWS2LS log that the XPATH entries for the resulting schema elements explicitly called out the nested sequence of type-namespace names mentioned in the WSDL.
Whereas without the schema parameter setting elementFormDefault="qualified", my original WSDL resulted in XPATH entries with "null" in place of the desired type-namespace names - that's running both his and my versions of DFHWS2LS.
I - and evidently others on the web - cannot overstate the significance of this parameter, elementFormDefault, as the effort to debug has been substantial with arguably a lack of sufficient tools - especially on the CICS side.
IMHO, it would be nice if the DFHWS2LS utility could be made available as a freeware plugin for Eclipse - for perhaps no other purpose than diagnosing the WSDL.