Issue with JavaToHost transformation using EBCDIC encoding

[Benjamin]

Hello,

We are currently facing difficulties to generate cobol messages with the JavaToHost transformers. For our cobol messages, we uses the EBCDIC endoding Cp1147. The strange fact is that we don't have problems in the reverse way, from HostToJava.

Let's take a simple example.

Step 1 - In the input cobol message, a character '4' will be encoded 0xF4 in hexa.
Step 2 - When using the HostToJava transformer, the character will be converted in ASCII. We get 0x34 in hexa which is correctly converted.
Step 3 - When applying the reverse transformation (JavaToHost), we still get 0x34 instead of 0xF4. It looks like the conversion is not performed whereas we have specified the encoding 'Cp1147' in the corresponding input parameter of the transformer.

Do you believe we are doing something wrong or there is an issue to convert from ASCII to EBCDIC? The version we are using is 1.5.5.

Thanks for your help.

Regards,

Benjamin jarle.

[Fady]

Hello Benjamin,

Have you tried IBM01147 instead of Cp1147, it could make a difference.

Fady

[Benjamin]

Hello Fady,

We tried with IBM01147 and, indeed, it is working fine now. Thanks for the solution!

Regards,

Benjamin.

Le vendredi 1 mars 2013 10:11:03 UTC+1, Benjamin a écrit :

[Fady]

I agree that this should be fixed.

It is not as easy as accepting the Cpx version of the IBMx character set though.

The code you pointed out was added to avoid an expensive asccii/ebcdic conversion . Performance tests demonstrate that the most costly part of the conversion is String.getBytes(<charset>).

Another phenomenon is that a relatively large number of people use legstar in non ebcdic evironments. So the code page is not always an ebcdic code page.

So I tried to infer from the charset name if it was EBCDIC or not.

Testing the IBM prefix is not the best thing to do though. We should probably replace that with an explicit list of charsets known to be EBCDIC. I will look into that.

Thanks for investigating.

Fady