During testing of a legacy web app ported from Solaris WAS 6.1 to z/OS WAS 6.1 we've stumbled upon a character translation problem that has a simple (Generic JVM argument: -Dfile.encoding=367), yet apparently unsupported fix on z/OS. I had hoped to get a specific example of a problem that would occur in changing this from the default of ISO8859-1 to determine if this change poses a risk.

The real problem is that the webapp never checks the validity of XML it generates and app changes are prohibited for various reasons. The file.encoding value on the default US Solaris install is ISO646-US (7-bit ASCII) which conveniently converts characters over hex 7F to hex 3F (Question mark). This has masked a defect in the application. Upon porting to z/OS (using ISO8859-1), characters above 7F are translatable and now causing the XML parser in Internet Explorer to choke. Of course this has nothing to do with z/OS WebSphere. It would happen on Linux or Windows as well. The easiest fix on z/OS has been to add -Dfile.encoding to the webapp's JVM arguments, but WAS support at IBM considers this "unsupported."