Hello, I am needing to unmake decimals that are in natural from java. Has anyone done any of this? Do you know in what format they are packaged or do you know a java library?
Thank you very much!
José,
how are you getting that data into Java ?
I’ll tell you, the system was in a Natural / db2 environment and we migrated these tables to a Postgresql database. The problem that I have that the P (13,2) fields that were redefined within a char field are packed and I cannot read them. I put an example:
2 YEAR1_MESES_GL3
2 REDEFINE ANIO1_MESES_GL3
3 MONTHS1 (P13,2 / 1: 13)
Nice one ! (nfc)
Check into the IBM Data Access Accelerator Library
1 Like
Thanks for the answer! The problem I have is that the information is already migrated to Postgresql! I need to be able to read that field that was migrated as a string from a Java program through jdbc to the postgresql table. IBM no longer participates.
This is just a class library provided by IBM, it includes functions for transformation of packed decimal data.
Oh, okay! I’ll investigate!
Thanks a lot.
You didn’t specify your source and target platforms. If the DB2 data is stored as EBCDIC characters and the ProgreSQL is stored as ASCII, your embedded COMP-3 values will have been corrupted during the transfer.
Let’s take the value 40,404 as an example. In DB2 the COMP-3 field will be x’40404F’ which is alpha ’ |’ (2 spaces and a logical nor). After conversion of the alpha characters to ASCII, the COMP-3 value will be x’20207C’, or 20,207.
Another example: -40,406 becomes 20,205. That is, x’40406D’ translates to x’20205F’.
In most cases, the result is an invalid COMP-3 value.
Good afternoon, I can not find the library in the link you attached. Where could I get it from?
It tells me to use the com.ibm.dataaccess package but I don’t see where the library is.
Thank you.
Hello,
As when migrating from mainframe to Windows, the migrator converted me from EBCEDIC to ASCI and from there it was uploaded to the Postgresql base. What I was thinking of doing was before running the unmaking was run an ASCI to EBCEDIC converter.
I don’t believe you will be able to correct the damage by running an ASCII-EBCDIC conversion, but this depends on what exactly happened during the EBCDIC-ASCII conversion. I suspect that many hex codes were converted to spaces and cannot be reversed properly.
As an example, I used Natural’s utility to convert EBCDIC to ASCII to EBCDIC and the result did not match the original string.
I suggest you pass the following set of “characters” through your process to see if you get your anticipated result. These are all the byte values found in COMP-3 fields, as they might be defined in a Natural program:
1 #ORIG (A130) INIT
<H'00010203040506070809' - H'0C0D0F'
-H'10111213141516171819' - H'1C1D1F'
-H'20212223242526272829' - H'2C2D2F'
-H'30313233343536373839' - H'3C3D3F'
-H'40414243444546474849' - H'4C4D4F'
-H'50515253545556575859' - H'5C5D5F'
-H'60616263646566676869' - H'6C6D6F'
-H'70717273747576777879' - H'7C7D7F'
-H'80818283848586878889' - H'8C8D8F'
-H'90919293949596979899' - H'9C9D9F'
>