COMP-3 byte calculation is not working as expected

[Loganhex2021]

Describe the bug

COMP-3 byte calculation is not working as expected. If COMP-3 is provided in parent field, then total bytes will be the sum(child bytes)/2 + 1. But in cobrix, the logic is applied to child level which increases the bytes size.

Code snippet that caused the issue

  spark.read
   .format("cobol")

Expected behavior

A clear and concise description of what you expected to happen.

Context

• Cobrix version:
• Spark version:
• Scala version:
• Operating system:

Copybook (if possible)

         01  RECORD.
           05  FIELD1    COMP-3.
               07 COL-1 PIC S9(7)
               07 COL-2 PIC S9(7)
               07 COL-3 PIC S9(7)

Here expected bytes = ((7+7+7)/2) +1= 11. But as per cobrix ((7/2)+1)+((7/2)+1)+((7/2)+1) = 12 @yruslan

[yruslan]

This is an interesting use case that we haven't encountered yet.

So far the workaround would be to change the copybook to:

         01  RECORD.
           05  FIELD1 PIC S9(21) COMP-3.

A question regarding your example. Do fields at level 7 miss '.' at the end?

[Loganhex2021]

This is an interesting use case that we haven't encountered yet.

So far the workaround would be to change the copybook to:

         01  RECORD.
           05  FIELD1 PIC S9(21) COMP-3.

A question regarding your example. Do fields at level 7 miss '.' at the end?

yes, There is '.' at the end of 7, While pasting the copybook , i missed it

[yruslan]

Please, provide some example bytes (11 bytes of a valid record).

I'm trying to understand how 3 signed fields could be combined the way you say.

[Loganhex2021]

Please, provide some example bytes (11 bytes of a valid record).

I'm trying to understand how 3 signed fields could be combined the way you say.

Data: 123456712345678912345

Copybook: 01 MASTER-AREA-V2. 02 DDA-ACCT-MASTER. 03 WMS-STATEMENT-DATA. 05 WMS-STMT-COMP-DATA COMP-3. 07 WMS-STMT-NO-CREDITS PIC S9(7). 07 WMS-STMT-ITEMS PIC S9(9). 07 WMS-STMT-LINES PIC S9(5).

While reading data: The data splits into 7, 9, 5 character lengths to respective columns

[yruslan]

I see, thanks. Let's keep this issue open, but it would take time to fix. Currently the decoding is built on assumption that each primitive field have independent byte boundaries. But this example requires splitting numbers in the middle of a byte.

As a workaround, you can use

05 WMS-STMT-COMP-DATA PIC S9(21) COMP-3.

and use Spark to split back the number