Unwanted characters while converting BigDecimal and Long values

[GoogleCodeExporter]

What steps will reproduce the problem?

This is my COBOL copybook file.

000001        01  NEW-REC.                                                  
000002            03  VALUE1                   PIC S9(0011).                    

000003            03  VALUE2                   PIC S9(0011)V99.  

XSD is generated as follows,

....
<cb:cobolElement cobolName="VALUE1" levelNumber="3" picture="S9(0011)" 
signed="true" srceLine="2" totalDigits="11" type="ZONED_DECIMAL_ITEM"/>
....
<cb:cobolElement cobolName="VALUE2" fractionDigits="2" levelNumber="3" 
picture="S9(0011)V99" signed="true" srceLine="3" totalDigits="13" 
type="ZONED_DECIMAL_ITEM"/>
....

The corresponding Java class is converted to long and BigDecimal
    protected long value1;
    protected BigDecimal value2;

Am using the following Java code to convert 

    NewRec rec = new NewRec();
    rec.setValue1(new Long("123456"));
    rec.setValue2(new BigDecimal("999"));
    byte[] result = transform(new NewRecTransformers(), rec);
    String str = new String(result, "SHIFT_JIS");
    System.out.println(str);

What is the expected output? What do you see instead?
Output:

    0000012345000000009990

Characters such as 0x6 and 0x0 is getting appended to the output string.
That is 0x6 is getting appended after 0000012345, and 0x0 is getting appended 
after 000000009990 .

Also If am not setting any values by default the char 0x0 is getting added to 
the result.

    0000000000 000000000000 

0x0 is getting appended after 0000000000 , and another 0x0 is getting appended 
after 000000000000 .

What version of the product are you using? On what operating system?
Legstar version - 1.5.2
Operating System - Windows 7 professional 64 Bit

Here is my query,

1) Is the values (0x6 or 0x0) being added to the string is correct?
2) I don't want any characters which is not a valid XML character. XML wont 
allow characters like 0x6, 0x0 etc., Is there any workaround.

Original issue reported on code.google.com by jjayamohan on 25 Feb 2013 at 2:16

[GoogleCodeExporter]

Sorry forgot to add the transform method, My transform method looks like below,

    private static byte[] transform(IHostTransformers transformer, Object obj) {
        try {
            return transformer.toHost(obj, "Shift_JIS");
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

Also, I would like to add that for conversion from COBOL book to Java am using 
LegStar Eclipse plugin v.1.5.2.

Original comment by jjayamohan on 25 Feb 2013 at 2:26

[GoogleCodeExporter]

Can you clarify what your target host system is? Is that a z/OS mainframe? Is 
it expecting Shift_JIS or CP930?

Original comment by fady.mou...@gmail.com on 25 Feb 2013 at 7:48

[GoogleCodeExporter]

Original comment by fady.mou...@gmail.com on 25 Feb 2013 at 7:48

• Changed state: Accepted

[GoogleCodeExporter]

The target host system is AS/400 (Application System/400). My service is not 
directly communicating with the target host. 
It is just copying the result files to an FTP which expects in Shift_JIS format.

Original comment by jjayamohan on 25 Feb 2013 at 7:53

[GoogleCodeExporter]

Ok, I see.

The problem is this: Your 2 variables, VALUE1 and VALUE2 are declared as COBOL 
zoned decimal. Zoned decimals are z/OS specific numerics where the last byte 
holds the sign with a technique called overpunch.

In the case of 123456, the Shift_JIS is 0x3030303030313233343536 but the 
overpunch replaced the last 0x36 by 0x06 because this is a positive numeric.

In your case, you don't want to convert to Zoned decimal.

The only solution I can think about is that you change the COBOL definitions. 
For instance  PIC S9(0011) becomes PIC X(0011). This means you will have to 
convert your numerics to strings on the java side.

Original comment by fady.mou...@gmail.com on 25 Feb 2013 at 8:30

[GoogleCodeExporter]

Another alternative is to do this:

        01  NEW-REC.
            03  VALUE1       PIC S9(0011) SIGN LEADING SEPARATE.
            03  VALUE2       PIC S9(0011)V99 SIGN LEADING SEPARATE.

This is better than PIC X because LegStar will still map these fields to 
numeric fields.

Be aware though that with this definition, VALUE1 now occupies one more byte 
(same for VALUE2).

Original comment by fady.mou...@gmail.com on 25 Feb 2013 at 1:20

[GoogleCodeExporter]

Thanks for your reply.
I tried using the below and was still getting stings like 0x6. 

01  NEW-REC.
  03  VALUE1       PIC S9(0011). SIGN LEADING SEPARATE
  03  VALUE2       PIC S9(0011)V99. SIGN LEADING SEPARATE

Leaving me with option of changing to numerical in copybook to String. PIC 
X(0011). Which I wont prefer personally, but I can see I don't have any other 
option.

Original comment by jjayamohan on 27 Feb 2013 at 5:26

[GoogleCodeExporter]

I  tested the sign leading separate and it does work. You should not be getting 
the 0x6 anymore. Make sure you regenerate the xsd and the transformers. Please 
attach the xsd if you still get the issue.

Original comment by fady.mou...@gmail.com on 27 Feb 2013 at 6:35

[GoogleCodeExporter]

Sorry I was getting 0x3. I had regenerated the XSD and transformers, Still I 
was getting the 0x3 characters.

I have attached the XSD for your reference. It is still generated as 
ZONED_DECIMAL_ITEM (Don't know why). I am testing using below code.

    NewRec rec = new NewRec();
    rec.setValue1(123);
    rec.setValue2(new BigDecimal("2.0"));
    byte[] result = transform(new NewRecTransformers(), rec);
    String str = new String(result, charset);
    System.out.println(str);

Original comment by jjayamohan on 27 Feb 2013 at 7:29

Attachments:

• Generated.xsd

[GoogleCodeExporter]

This can't be the new XSD. When the Cobol contains SIGN LEADING, the 
corresponding XSD markup should show signLeading="true" signSeparate="true".

Original comment by fady.mou...@gmail.com on 3 May 2013 at 6:26

[GoogleCodeExporter]

Product behaving according to specs.

Original comment by fady.mou...@gmail.com on 31 May 2013 at 7:17

• Changed state: WontFix