Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cobrix converting incorrectly number instead of string value for Hexa C4, C5 values #474

Closed
Loganhex2021 opened this issue Feb 22, 2022 · 7 comments
Labels
question Further information is requested

Comments

@Loganhex2021
Copy link

While reading EBCDIC file with Cobrix Library , noticed that it converts incorrectly as numbers for few Hexa value instead of null.

CopyBook:
RecordIdentifier PIC 9(1)
RecordName PIC x(10)

Sample Data:
Hex Value Cobrix Output Expected Output
f9 9 9
c4 4 null ( equivalent data -> D since it is number in copybook so it should null )
c5 5 null ( equivalent data -> E since it is number in copybook so it should null )
d6 null null

Could you please clarify why it is happening like this ?

@Loganhex2021 Loganhex2021 added the question Further information is requested label Feb 22, 2022
@Loganhex2021
Copy link
Author

@yruslan - Can you please clarify here

@yruslan
Copy link
Collaborator

yruslan commented Feb 23, 2022

This is signed overpunch when the sign of the number is embedded into the number using an extended table. 0xC4 = 'D' = +9, which is a valid 9(1) number.

@Loganhex2021
Copy link
Author

Thanks @yruslan , Actually we are getting 4 as output instead of null for the 0xc4.
same thing for 0xc5, that it provides 5 as output instead of null.
But in on-prem system does correctly output as null for this scenarios.
can you please suggest how it should be fixed ?

@yruslan
Copy link
Collaborator

yruslan commented Feb 23, 2022

A couple of questions regarding the use case:

  • Which version of Cobrix are you using (Both for the on-prem app and for the above example)?
  • What is the code snippet that you use to read the data?
  • What are the exact fields definitions for this example, and for your on-prem case? (you can rename these fields if it is sensitive)
  • Could you please elaborate on the fact that the field contains some data (0xC4), but you expect null there? Why would the system populate the field at all if the content is null?

0xC4 is a valid number, and it equals 4 (with overpunched '+', so actually +4). Only one sign overpunch is allowed, so bytes 0xC4 0xC4 won't result in 44, but in null. That might be why you are getting nulls in some cases.

Please, take a look at this page to understand why this is happenning: https://en.wikipedia.org/wiki/Signed_overpunch

@yruslan
Copy link
Collaborator

yruslan commented Feb 23, 2022

After checking the logic once more I think I can see why this is confusing. It seems Cobrix is too permissive and allows sign overpunching for unsigned data (with PIC like '9(7)'). But sign overpunching should be available only for signed fields (PIC of 'S9(7)').

Here is the proposed change: #475
You can test if it works for you by building this branch: https://github.com/AbsaOSS/cobrix/tree/feature/474-stricter-sign-overpunching

@Loganhex2021
Copy link
Author

thanks @yruslan , I will check and let you know.. we don't have permission to check on-prem code and configuration in the current project :)

@Loganhex2021
Copy link
Author

Fix working fine, Thanks a lot @yruslan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants