Handling REDEFINEs with different length

[Ramiro González Maciel]

Hi everyone

I have this case ( simplified version ):

15  INPUT              PIC  X(840).     

                                                                 

15  CARS      REDEFINES          

           INPUT.                              

                                                                 

20  BRANDS              OCCURS 20 TIMES    

                                  INDEXED BY I-CLSR. 

25  BRAND              PIC  X(40).      

So INPUT length is 840, but the redefine length is 800 bytes ( 20 * 40... )

When I generate the host bytearray from the redefined case, I get only 800 bytes.

I can see in the binding class that this is so:

[...]

        _xxxWrapper.setByteLength(800);

        _xxxWrapper.setItemByteLength(40);

        _xxxWrapper.setMinOccurs(20);

        _xxxWrapper.setMaxOccurs(20);

[...]

but I need to generate the full length.

How can I solve this case without editing the COMMAREA definition?

Thanks

      Ramiro

[Fady]

Strictly speaking, that branch is 800 bytes long since the maximum number of occurrences is 20.

What exactly is the issue you are facing?

Fady

[Ramiro González Maciel]

Hi Fady thanks for your answer and for your great work on this project.

So the problem I'm facing is that when I generate the host bytearray from Java, I get two arrays with different length depending on which branch I choose.

If I set the INPUT, I get the 840 bytes.

If I set the CARS, I get 800 bytes.

I expect to get the same length in that part ( the copybook is much longer, 31900 bytes, with some other REDEFINES below even , so everything below that gets shifted ).

So for example, if I build a Java object with the CARS option, transform it to a bytearray and try to transform it back to java, it will break because it's shorted than expected with the default strategy.

I'm no COBOL expert so my expectations may be wrong, but I was hoping that the transformation would somehow fill the misssing 40 bytes so to get the same message length.

thanks again

[Fady]

Humm, normally legstar does the appropriate offsetting so that the fields following a Choice are at a fixed position.

I just did a test with the sample you sent, adding a field after the REDEFINES like so:

       01   COMMAREA.

            15  INPUT              PIC  X(840).

            15  CARS      REDEFINES INPUT.

                20  BRANDS OCCURS 20 TIMES.

                    25  BRAND              PIC  X(40).

            15  FOOTER             PIC X.

            

Here is my testing code:

    public void testApp() throws Exception {

        

        Commarea c = new Commarea();

        c.setFooter("Z");

        Cars cars = new Cars();

        for (int i = 0; i < 20; i++) {

            Brands b = new Brands();

            b.setBrand("AB" + i);

            cars.getBrands().add(b);

            

        }

        c.setCars(cars);

        

        CommareaTransformers tf = new CommareaTransformers();

        byte hostData[] = tf.toHost(c);

        assertEquals("c1c2f040404040404040404040404040404040404040404040404040404040404040404040404040c1c2f140404040404040404040404040404040404040404040404040404040404040404040404040c1c2f240404040404040404040404040404040404040404040404040404040404040404040404040c1c2f340404040404040404040404040404040404040404040404040404040404040404040404040c1c2f440404040404040404040404040404040404040404040404040404040404040404040404040c1c2f540404040404040404040404040404040404040404040404040404040404040404040404040c1c2f640404040404040404040404040404040404040404040404040404040404040404040404040c1c2f740404040404040404040404040404040404040404040404040404040404040404040404040c1c2f840404040404040404040404040404040404040404040404040404040404040404040404040c1c2f940404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f0404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f1404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f2404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f3404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f4404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f5404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f6404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f7404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f8404040404040404040404040404040404040404040404040404040404040404040404040c1c2f1f940404040404040404040404040404040404040404040404040404040404040404040404000000000000000000000000000000000000000000000000000000000000000000000000000000000e9", HostData.toHexString(hostData));

        

        Commarea c1 = tf.toJava(hostData);

        assertEquals("Z", c1.getFooter());

        assertNotNull(c1.getCars());

        assertNull(c1.getInput());

        

        

    }

Seems to work fine. Are you sure the issue is right after the REDEFINES?

Fady

Le mercredi 17 décembre 2014 19:37:52 UTC+1, Ramiro González Maciel a écrit :

[Ramiro González Maciel]

I confirmed that depending on which choice I create in the object structure, I get bytearrays with different length.

Now, the commarea is much more complex than in this "CARS" example, so I'm uploading it so you can check see the problem with the real one

The problem is with the REDEFINES of 

15  CA-ZZ90-RECURRING-INPUT              PIC  X(840).    

 

I'm attaching a test where I create two different object structures, generate the bytearrays, and they differ in length.

In one I create a:

       15  CA-ZZ90-DSRBRIBUTION-CLUSTERS      REDEFINES          

           CA-ZZ90-RECURRING-INPUT.                              

and in another one

      15  CA-ZZ90-CATEGORY-CRITERIA         REDEFINES           

           CA-ZZ90-RECURRING-INPUT.                              

I'm not sure where's the problem and where to look at the legstar source code

Thanks

         Ramiro

[Ramiro González Maciel]

Hi Fady

            I debugged the CobolVisitor classes and I think the problem is with nested REDEFINEs. 

CobolMarshalVisitor, line 186:

                    /* Save the visitor offset context */

                    int savedOffset = getStartOffset();

                    alt.accept(this);

                    /*

                     * If offset was succesfully incremented, we consider we

                     * found a valid alternative, just get out of the loop.

                     */

                    if (savedOffset < getStartOffset()) {

                        chosenAlternative = alt;

                        break;

                    }

I think the problem is that getStartOffset resets the virtualOffset. So if the REDEFINED element is the last child, the Visitor pops up, if that is another REDEFINED, the same method will call the getStartOffset and reset the virtualOffset, and so it gets lost.

I made a patch to use a "non destructive version". My tests work ok, all the cases generate the same length. I should made a more syntetic case but may be easir for you to test it.

I'm attaching the patch

Thanks

Ramiro

[Fady]

Sounds excellent. I have been swamped for the last 2 days but I will try to find time tomorrow to test your patch.

Thanks a lot for contributing back your fix! This is very appreciated.

Fady

[Fady]

Confirmed as a bug. Opened a bug report here https://code.google.com/p/legstar/issues/detail?id=185

Thanks again Ramiro

[Ramiro González Maciel]

You're welcome Fady, I'll follow the bug

Ramiro