Convert Mainframe hexadecimal to integer
Moderators: chulett, rschirm, roy
Convert Mainframe hexadecimal to integer
Hello everyone, I am new to the forum and to Datastage. We have a requirement to pull a mainframe file over to our unix server that will be processed by Datastage and loaded into Greenplum. We successfully pulled and loaded the data into Greenplum. We are having an issue with one field where it is defined as a PIC S9(04) COMP field (hexadecimal) on the source and an integer on the target table. The field is successfully loaded but the values loaded are not correct.
source field listed as binary 4 in datastage complex file.
target field listed as smallint.
EX.
source field value = x'058c'
target field value = -29691
expected target field value = 1420
Currently the field is a one to one mapping between source and target. We are allowing Datastage to do the conversion natively.
Any suggestions on how we can correct this issue?
Any feedback is appreciated.
source field listed as binary 4 in datastage complex file.
target field listed as smallint.
EX.
source field value = x'058c'
target field value = -29691
expected target field value = 1420
Currently the field is a one to one mapping between source and target. We are allowing Datastage to do the conversion natively.
Any suggestions on how we can correct this issue?
Any feedback is appreciated.
The general caution in using EBCDIC data is to do explicit conversions for all numeric fields. In this case, you need to have a DecimalToDecimal() function for the binary integer field, and be sure the receiving column has the signed attribute.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
Thank you for your initial response FranklinE.
We tried the decimaltodecimal function in the transform step and its returning the same value (-29691). We also used the "View Data" option inside the complex file element its displaying the same(-29691).
Any other items that you think we should verify?
Thank you.
We tried the decimaltodecimal function in the transform step and its returning the same value (-29691). We also used the "View Data" option inside the complex file element its displaying the same(-29691).
Any other items that you think we should verify?
Thank you.
You're quite welcome. I'm an old mainframe developer, and the author of the FAQ linked at the bottom of my posts. Glad to help.
Things to check.
In CFF stage, on the Record Options tab:
Byte-order should be native-endian for most systems, but your file might need a boost there. Experiment with using big-endian first; if that doesn't do it, try little-endian.
Data format should be set to binary.
Also check the attributes for the COMP field. It might have local settings along those lines that are causing your problem.
Things to check.
In CFF stage, on the Record Options tab:
Byte-order should be native-endian for most systems, but your file might need a boost there. Experiment with using big-endian first; if that doesn't do it, try little-endian.
Data format should be set to binary.
Also check the attributes for the COMP field. It might have local settings along those lines that are causing your problem.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
I'm curious why the mention of "hexadecimal" and showing the source field value as x'058c' when a COBOL COMP field is binary storage. That seems like a disconnect to me... but then it's been a long time since I've actually had to deal with an EBCDIC file.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Craig,
One can interpret "hexadecimal" to mean "curse the ten".
Anyway, I'm glad there's a good endian to this story.
One can interpret "hexadecimal" to mean "curse the ten".
Anyway, I'm glad there's a good endian to this story.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
C:/DOS
C:/DOS/RUN
RUN/DOS/RUN
I think they should call them Granddad Jokes...
C:/DOS/RUN
RUN/DOS/RUN
I think they should call them Granddad Jokes...
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
mostly unrelated but intel and some other cpus have an explicit endian flip machine instruction. If you have a LOT of numbers to flip, beware of systems that rotate bytes if the direct approach is available. The difference for large volumes can go from hours to seconds, literally -- esp for 32 and 64 bit flips.