Problem with Character Ñ in XML data frame using Cics web services

[Mario Izaguirre]

Hi all.

 

We have a problem.

 

We just implement web services from windows to CICS-TS, everything went well but suddenly appeared a very rare case, a person wanted to make a modification to a customer who bears the Ñ character in one of his last name, the proxy program Not terminates in error only ends and returns control to the calling program.

 

I try to follow the CWBA transaction using CEDA and seeing with the data frame, I see that the character depicted in ASCII Ñ leaves the “dot” character and hexadecimal value is represented by 69.

 

  ADDRESS: 07B081C0                                                        

07B081C0   000000   FF508194 975E5C50 8194975E C3C3D6D5   .&*&CCON

07B081D0   000010   E3D95081 94975E4F F0F0F1D4 D6C4C94F   TR&|001MODI|

07B081E0   000020   50819497 5E508194 975E4FF0 F0F4F2F2   &&|00422

07B081F0   000030   F3F9F0F2 F84F5081 94975E50 8194975E   39028|&&

07B08200   000040   4FF0F0F5 D4E469D6 4F508194 975E5081   |005MU.O|&&a

07B08210   000050   94975E4F F0F0F6F0 F8F1F0F2 4F508194   mp;|00608102|&am

07B08220   000060   975E5081 94975E4F F0F0F7D1 D54F5081   p;&|007JN|&a

07B08230   000070   94975E50 8194975E 4FF0F0F8 F0F1F24F   mp;&|008012|

07B08240   000080   50819497 5E508194 975E4FF0 F0F9C34F   &&|009C|

07B08250   000090   50819497 5E508194 975E4FF0 F1F0D4E4   &&|010MU

07B08260   0000A0   69D6E9D9 D6C4D9C9 C7E4C5E9 C3C1D9D3   .OZRODRIGUEZCARL

 

 

Most curious that if I insert the character Ñ twice if the program works.

 

&amp = These registers separators are used in the data frame.

 

Any clue, someone happened to this, I have the idea to use the spacers & in combination with Ñ character does not like the XML parser in CICS environment ...?

 

 

 

Regards.

 

 

Mario

 

 

 

 

 

 

[Martin Truebner]

Mario,

the strange character in the subject and the fact that noone answered
up to now let me to post an experience I had:

We did set up a service to request to data from some ASCII based
platform- The documentation said no word about soap but it was obvious
that they had an envelope with a request and and answer- just the
headers were nothing we could constrcut with IBMs base (and free)
offering.

I wrote code to combine calls to HTTP service and then to XML (which
are also supplied by IBM free of charge). I did a presentation during
WAVV 2013 about it.

Now to the problem: as long as we did request valid data it came back
with valid XML in the soap-envelope and valid information in the other
parts of the communication- but then we did ask for an invalid number
they came back with and "invalid" HTTP status line.....

the RFC says:

http-version and a comma and a number and a comma and a string in
us-ascii. LF terminates it all

Unfortunatly they came back with:

http 1.0, 123 , Ausführung nicht möglich

as you might know the german umlauts are not part of 128 ASCII
(or us-ascii).

It took IBM a few minutes (after we finally supplied buffertraces and
all) to identify the cause. It took the supplier of the wrong data (and
us to convince them first) 4 month.

It is fixed now.

Good luck with your problem.

What you have not stated is: where does this strange character occur?

What is the exact error message you get? Might want to use
SOAPSUI (or the like tools) to identify what is exchanged.

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l

[Mario Izaguirre]

Hello Martin.

For us it is also again use the CICS Web services.

Is something very strange what is happening, and Regarding your questions: "does not give any error message, but the program ends and returns control to the calling program, the client has provided me the message that captures in your distributed application, " expected 'text/xml' ".

Also tells me that if the user types 2 or more times the character Ñ if that works (exam: MUÑÑOZ), also it works if the user type the character N, if the user types an accented vowel or accent will also work. Only gives problems when the user types a single letter Ñ. (exam: MUÑOZ).





TIA

Mario


-----Mensaje original-----
De: vse-l-bounces+mizaguirre=circu...@lists.lehigh.edu [mailto:vse-l-bounces+mizaguirre=circu...@lists.lehigh.edu] En nombre de Martin Truebner
Enviado el: jueves, 30 de mayo de 2013 17:32
Para: vs...@lists.lehigh.edu
Asunto: Re: Problem with Character Ñ in XML data frame using Cics web services

[ifra...@googlemail.com]

Hello Mario,

these charatcers are codepage dependent. When using Web Services the data needs to be translated from an ASCII based codepage to EBCDIC. To allow correct conversion of these special characters you must make sure that you choose the right codepages.

Make sure that the SOAP request (XML) uses UTF-8 while it is 'in the network'. UTF-8 is unicode and supports all these special characters.

On VSE you need to make sure to configure an EBCDIC codepage that supports this special character, i.e. a Spanish codepage. You can configure this for SOAP in option phase IESSOAPO. You can generate one using skeleton SKSOAPOP in ICCF lib 59. Make sure you have CLNT_ACP = 'UTF-8' and CLNT_ECP = the Spanish EBCDIC codepage. The default EBCDIC codepage is IBM-1047 (US English) which probably does not have that spanish charatcer.

Hope this helps.
Kind regards, Ingo Franzki

[Martin Truebner]

Boy am I glad that Ingo showed up and chimed in......

Here is an opinion on the double special thingie (I do not dare to call
it X'69' in EBCDIC)- some component makes it appear-

XML is per definition unicode-8. Whatever makes it work with two
of the same kind is doing it wrong. It may be that you are
dealing with at a partner that has no clue on the codeset to use for
XML and uses whatever codeset that partner has in use and ends up
sending you some code in codepage 4711 (I made that up) and by luck
this makes sense in unicode-8 (when send as two char in a row).

[mick poil]

I have no real experience of SOAP and it was developed by VSE not us, so I am not really able to help.

The only thing that I can say is that CICS translation of EBCDIC in dump format as above will only normally use the standard translate table as per your System x Reference Summary card not code page 37, and substitute a "." where there is no "valid" display character.

Mike

[ifra...@googlemail.com]

I checked further:

In EBCDIC codepage 1047 (US) X'69' is in fact that 'Ñ' character (see http://www.tachyonsoft.com/cp01047.htm). This proves that the default EBCDIC codepage was used. The memory display shows the data already translated to EBCDIC (1047). As Mike noted, the display only shows printable charatcer, other characters are displayed as dot.

The VSE SOAP implementation does not use the CICS translation services (except for HTTP headers, etc). The content (i.e. XML data) is reveived in binary and is then translated by the SOAP engine using LE's ICONV services, which support a wide range of codepages, including UTF-8 and other unicode codepages.

I guess that you really should use the Spanish EBCDIC codepage IBM-284 (http://www.tachyonsoft.com/cp00284.htm). There the 'Ñ' character is at X'D1'.

Actually both codepages 1047 as well as 284 do contain the 'Ñ' character. So both codepages could be used and produce correct translated data. However, you need to make sure that you use that codepage that was used to enter the data originally. I.e. check the 3270 terminal settings which codepage is used there. If the users enter the data in 284, then you should also use that codepage with SOAP.

Kind regards, Ingo Franzki