PCLI Does Not Create Archives That Have German Characters in the File Name [1031395] On Windows, if a CodePage other than 1252 was used, the German umlaut characters were not displayed correctly. This has been fixed. Note: you can change or query your CodePage from a Command Prompt using the command chcp
Parameter CASE=RAISE does not work if comparing records with Polish National Characters present. Codepage 870 isused and module COMPAREE has been customized so there is no problem with print. The problem is the same whether UNICODE or EBCDIC is used.
Use correct code page for the ASCII to EDCDIC translation. Customer used to use code page 500 before migrating to dimensions 9.12. They took the default codepage with Dimensions 9.12 which is code page 1047.
What controls the way characters are displayed via the Eclipse plugin? Are there any variables that we can set to force the use of a correct character set or codepage when accessing Dimensions Requests via the Eclipse Rich plugin?
Using ZMF4ECL 7.1.2 the crosshatch/hash/pound/etc. symbol (i.e. '#') is not being handled correctly when used in staging dataset names for some international character sets. It appears that it is always being handled as a x’7B’ character regardless of the codepage /LCLCCSID in use.
