I am testing the "share" funtion to add new members to RTC source control. I find a problem that if the source code contains DBCS (double byte character set, in my case it's IBM-937), the double byte chars are not correctly converted to UTF-8 and cause build fail.


I did another test. If I create a new file without DBCS and share it. Then set the code page to IBM-937 with "I" . The I modify the code to add some Chinese characters. Then check-in it. The file is correctly converted to UTF-8. The build is also successful.

The problem is I can't set code page to the member before I share it. The file already persistant in incorrectly encoding once I click share.

The Code page parameter in the 0: setting doesn't help. I set it to IBM-937 but nothing impacted.

Does anybody using RTC ISPF in double environment? Do you get the same problem?

Hi Joseph,

I believe you're encountering a known issue with the ISPF client. Please see the following technote: http://www-01.ibm.com/support/docview.wss?uid=swg21461416

Your workaround of sharing the blank file, then setting the code page prior to giving it any contents is the recommended one. Alternatively, if you want the client to always default to using another character set besides the system default, you can set the ZLANG environment variable in your ispfdmn.conf configuration file:
export ZLANG=IBM-937

Finally, a quick note on the "code page" parameter in option 0. As you've noticed, that won't have any effect on filesystem operations in the ISPF client. That setting is only used to translate responses from the server. For example, if you had a repository workspace whose name contained DBCS characters, when the ISPF client asked the server for that name, those characters come back as unicode escape sequences (\u1234). In order to translate those sequences into native characters suitable for displaying to the user, the code page specified by that setting is used.


Thank you. The issue mentioned in the tech note is exactly the problem happened to me.

.......
Your workaround of sharing the blank file, then setting the code page prior to giving it any contents is the recommended one. Alternatively, if you want the client to always default to using another character set besides the system default, you can set the ZLANG environment variable in your ispfdmn.conf configuration file:
export ZLANG=IBM-937
..........

Hi Riendau,
Is there a enhancement request for technote swg21461416?

I applied the ZLANG setting solution in my test environment.
Although ZLANG setting can solve the issue for most of the members, there still some non-IBM-937 members in my customer's z/OS which cause trouble.

RTC client won't give any alert when sharing members with non-IBM-937 chars. But it shows load error when I try to load them to new workspaces.
The worse thing is RTC ISPF client won't show which member cause load fail. After I find them and share those file with binary mode, the new workspaces can be loaded.

I think RTC ISPF client can improve the share function to:
1. Allow specify binary or not. (Not just in 0: setting menu)
2. Allow to specify encoding.
3. Check if the member match the encoding for both the ZLANG setting and the encoding user specified when sharing members.