Topic
  • 2 replies
  • Latest Post - ‏2013-03-13T13:36:33Z by SystemAdmin
SystemAdmin
SystemAdmin
1086 Posts

Pinned topic DFHWS2LS in CICS vs RDz

‏2013-03-08T18:44:04Z |
Dear All,

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.

Best,
CB
Updated on 2013-03-13T13:36:33Z at 2013-03-13T13:36:33Z by SystemAdmin
  • mazogi
    mazogi
    109 Posts

    Re: DFHWS2LS in CICS vs RDz

    ‏2013-03-10T01:33:01Z  
    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
    Mode: mode
    Created: 23 Jul 2012 17:53
    Release:
    Build-Level: PM43883-20110817-1208

    This will tell you the dates of the versions you are running. Most likely your version is newer than your colleague's.

    Thanks,

    Gary
  • SystemAdmin
    SystemAdmin
    1086 Posts

    Re: DFHWS2LS in CICS vs RDz

    ‏2013-03-13T13:36:33Z  
    • mazogi
    • ‏2013-03-10T01:33:01Z
    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
    Mode: mode
    Created: 23 Jul 2012 17:53
    Release:
    Build-Level: PM43883-20110817-1208

    This will tell you the dates of the versions you are running. Most likely your version is newer than your colleague's.

    Thanks,

    Gary
    Going on memory only for now, my DFHWS2LS version, 1.6.00, matched that of my colleague's CICS environment, but I don't know yet whether my build level (PM43883-20110817-1208) matches his.

    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.

    Best,
    CB