Outbound translation is controlled by the CICS module DFHCNV. You may need to assemble a replacement table specifying which code pages you use. Plus, you may need to add analyzer code if you use more than one code page on the browser clients. See the section
2.5.6 Code page considerations for Web commarea applications
in the IBM CICS Internet Guide ( or the equivalent for your release ).
Inbound translation is more complex. DFHCNV does most of the work, but there will be "escaped" characters in GET/POST parameter data in the form "%xx" where the xx is the ASCII hex representation of the character. Using the @I$IPOST routine to retrieve the data converts these, but again it uses a US code page. The translate table in the module could be zapped, or you could request the new version of this routine as a test solution, or wait until it is confirmed and published. It has an extra call you can make to convert a string received via GET, and allows a user translate table to be linked in to override the built-in one.
One final quirk to watch for is that TN3270 interfaces often use a different translation from CICS/Web. The square bracket characters are commonly different and the recommend zap to PMSTRND converts both "dialects" to the values that work outgoing in the USA. There may be other characters that have a similar problem.
John West
CA-Ideal Development