Question & Answer
Why is z/OS Connect Enterprise Edition (zCEE) converting spaces sent back by CICS Transaction Server for z/OS (CICS TS) to unicode control characters? I am running zCEE on z/OS 2.2 at this level:
WebSphere Application Server 22.214.171.124, WAS FOR Z/OS 126.96.36.199, z/OS
Connect 03.00.04 (wlp-1.0.17.cl170220170523-1818)
I am setting up a sample to show zCEE calling C program in CICS.
When I tested the application programming interface (API) to zCEE, in the JSON I get back, all the spaces
are replaced with a unicode value of \u0080, which according to the unicode doc is a control character, not a space. My program issues an EXEC CICS INQUIRE ASSOCIATION and the DNAME and REALM returns ASCII x'20' blanks and these are being converted by zCEE to the u0080 in the JSON.
The IBM documentation for CICS Transaction Server describes the DNAME value for the INQUIRE ASSOCIATION as...
Returns the 1- to 246-character distinguished name padded with trailing ASCII blanks. Distinguished names are represented in UTF-8 encoding. If a distinguished name is not available for the task, DNAME returns ASCII blanks.
...so although the CICS region is using EBCDIC code page 037 and the zCEE server data conversion will translate EBCDIC, when the zCEE server gets the x'20' ASCII space, it correctly translates the 0x20 in CP 037 to a control character (Digit Select), which maps to unicode 0080 - this was being converted as expected. A space character in CP 037 is 0x40, which translates to unicode 0020 (0x20 is a space character in other codepages, however not in code page 037.
You might want to consider using DFHCNV or the iconv() function in your program to convert the INQUIRE ASSOCIATION from ASCII to EBCDIC codepage and let the zCEE data transformation to JSON convert.
You might also want to consider submitting an IBM Request-For-Enhancement (RFE) to request z/OS Connect EE treat individual fields with their own codepage.
IBM zCEE L2 Support
CICS/TS CICSTS CICS TS CICS Transaction Server;zCEE
06 March 2018