EBCDIC DataSet JZOS and Websphere V6 for zOS

[nicomey]

Hi,

I have the following problem. I've write the following code to read my input mvs dataset (in EBCDIC format):

BufferedReader brdr = FileFactory.newBufferedReader(args[0]);
String line;
while ((line = brdr.readLine()) != null) {
System.out.println(line);
}

My input data set looks like (with hex data):
0258 000010008000001000800010008000000N:%2006
FFFF00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD26FFFF
02580000001000800000100080001000800000052C2006

Running the java program "native" with jzos, no error occurs. But running the same code within websphere some data are not correct encoded.
Output from websphere with same input data:
0258À:À:000010008000001000800010008000000NÂ:%2006
FFFF6262FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD626FFFF
02584040000010008000001000800010008000000522C2006

Here are some jvm-properties from websphere:

file.encoding.pkg = sun.io
file.separator = /
sun.io.unicode.encoding = UnicodeBig
ibm.system.encoding = Cp1047
file.encoding = ISO8859-1

Many thanks,
NicoMey

[dovetail]

First, are you using JZOS 1.2.3 from alphaWorks?

Under both scenarios, print out the value of ZUtil.getDefaultPlatformEncoding() to see what it is set to.
This encoding is initialized by the JZOS launcher to match your current z/OS Unix Locale/language, but if you are running under Websphere, then it will default to Cp1047. In a future release, it will be initialized to the default z/OS locale/language even if not running under the JZOS launcher.

So, assuming that when running under WebSphere ZUtil.getDefaultPlatformEncoding() is wrong, you can set it using ZUtil.setDefaultPlatformEncoding().

The other possibility is that the data is being read from ZFile exactly the same in both scenarios but that the output from System.out is being translated differently under Websphere. To verify this, you should dump out the Java String line in hex in both scenarios after you read the line:

for (int i=0; i<s.length(); i++ ) {
System.out.print(Integer.toHexString((char)line.charAt(i)) + ' ');
}
System.out.println();

Please let us know what you find; the solution may be helpful to others.

[nicomey]

Hello!

You're right. The data being read from ZFile ist in both scenarios the same. The problem is, that the output for the following code (after reading the file) is different in the two scenarios.

while((nRead = zFile.read(recBuf)) > 0) {
byte input[] = (new String(recBuf, 0, nRead, ZUtil.getDefaultOutputEncoding())).getBytes();
for (int i=0; i < input.length; i++ ) {
System.out.print(input);
System.out.print(' ');
}
}

Of course, the code is absurd (first translate to String and then back to byte[] with "getBytes"), but it shows the differences between the two scenarios.

My input EBCDIC data set has the following data "12345 (hex F1F2F3F4F5)".

Running the above code native with jzos version 1.2.2 and option "-Dfile.encoding=ISO8859-1" (like Websphere does) produces the following output: -15 -14 -13 -12 -11
These are the same byte values as read directly from ZFile.

Running the above code native within Websphere produces the following output: 49 50 51 52 53

Using the new jzos version 1.2.3, the same output (native with jzos and "-Dfile.encoding=ISO8859-1") is produced as running in WebSphere: 49 50 51 52 53

So, when using the new jzos version, the program is behaving the same in both scenarios.

Relating the different output from System.out: Under Websphere it is being differently translated (the hex values in both scenarios).

[dovetail]

What your latest example code does is:

- read bytes from a dataset without translation
- translate to String using JZOS ZUtil.getDefaultOutputEncoding()
- translate back to bytes using the JVM default file.encoding
- print the byte value as numbers to System.out

I'm not sure why you would see differences between JZOS 1.2.2 and 1.2.3,
unless the ZUtil DefaultOutputEncoding or -Dfile.encoding are being setup differently for some reason. (they must be)

Since Java bytes are signed 8 bit numbers, -15 -14 -13 -12 -11 = "F1F2F3F4F5". This means that under JZOS 1.2.2 , I don't think that you are actually getting -Dfile.encoding=ISO8859-1. It looks like it is set to some EBCDIC codepage, which is why when you do a round-trip translation you end up with the original bytes.

It would be helpful if you would add this to your test:

System.out.println("JZOS Output Encoding=" + ZUtil.getDefaultOutputEncoding());

System.output.println("Default file.encoding=" + System.getProperty("file.encoding"));

Also, you can run the JZOS launcher with LOGLVL='+T' to see what the output encoding is being set to.