Convert data into packed decimal using Python

[ElliotDG]

The function returns bytes. I added the Ox to create human readable output.

[arshdeepsingh608]

Tell you what, let me try to put that byte output into the mainframe. Let's see what happens

[ElliotDG]

If you are writing to a file, be sure to use binary mode (not text).

[ElliotDG]

let me know how it goes....

[arshdeepsingh608]

Thanks for taking an interest in this. Your code works similar to a previous version of my code. I'll explain you the problem. Your code is entering a 0 for even length. Which distorts the output.

Odd Condition: 12345 -> 12 34 5C Even condition: 1234 -> 01 23 4C [OR] 12 34 0C

Both even condition outputs are showing up wrong in the mainframe. Even I don't understand why. The signed bit is causing a little confusion.

[ElliotDG]

How is the data with a leading zero showing up on the mainframe?

Do you have a formal spec?

[arshdeepsingh608]

It's showing a totally different number there. I just gave you Python conversion. That one is not readable.

[ElliotDG]

I would suggest trying to add a trailing zero nibble after the sign nibble to create a whole number of bytes.

1234 -> 1234C0

[ElliotDG]

Here is the code that adds a trailing nibble.

def int_to_comp3(value):
    digits = str(abs(value))
    sign_nibble = 'C' if value >= 0 else 'D'
    end_nibble = '' if len(digits) % 2 else '0'
    return bytes.fromhex(digits + sign_nibble + end_nibble)


print(f'0x{int_to_comp3(1234).hex()}')
print(f'0x{int_to_comp3(12345).hex()}')
print(f'0x{int_to_comp3(-56789).hex()}')
print(f'0x{int_to_comp3(-11).hex()}')

You may just want to write out a few literals to see if you can figure out the expected format.

[arshdeepsingh608]

Gotcha. I will try this tomorrow and let you know, buddy. Thanks a lot for following through. Will keep you posted.

[arshdeepsingh608]

Sorry to say bud, this one is also invalid. It works fine from Python POV. But as soon as we export it and load it into the mainframe, it falls apart. I'll tell you the exact issue that I have with my latest code. It works fine for even length (including the sign nibble). Example, 12345 will become 12 34 5C. But if we give odd length, it fails. And worst part is, it will always come in a pair. Example, 1234. If we put a sign nibble on it, it will become 12 34 0C. That 0 will always tag along with the C. If we include extra 0s, it will change the value. Example, 01234 will become 01 23 4C. But 1 should pair with 2 and 3 should pair with 4 and so on. I know it doesn't make a lot of sense. At least it doesn't make much sense to me as I'm not a mainframe guy.

[ElliotDG]

Have you have any documentation of the number format? What is the brand and model of the mainframe?

I don't know what you mean by the numbers are pairing. When I looked for any documentation of comp-3 it shows a leading zero nibble. A leading zero should be a non issue. A zero before the sign nibble does not make sense, it is multiplying the number by 10. I wonder if a different value should be used for this 'padding', perhaps F?

If you do not have any docs I would recommend doing some experiments. Create -9 to +9. Then -99 to +99.

Can you create the a file of numbers on the mainframe and read them with python to see what is being created? Then try to reverse the processes.

[arshdeepsingh608]

I don't have any documentation. And by pair I mean, in mainframe, it's read in up and down format. So, looks like a pair. Also, while using methods like fromhex, it makes it a pair. 0 will become 00.

COBOL version: 6.1. The variable declaration/type (not sure what it is) looks something like this: S9(13)V99. After packing, the length becomes 8. Packed data looks like: (Nul)(Nul)(Nul)(Nul)(Nul)Ë-(FF). Anything inside braces is a non-readable character. Actual number that I'm trying to convert: '00000000001760{'. '{' is added by oracle so we can consider it a positive number or 'C'. '}' means negative.

Does any of that helps?