Convert Mainframe hexadecimal to integer

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
elinzeyjr
Participant
Posts: 9
Joined: Thu May 11, 2017 9:18 am

Convert Mainframe hexadecimal to integer

Post by elinzeyjr »

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.
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

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
elinzeyjr
Participant
Posts: 9
Joined: Thu May 11, 2017 9:18 am

Post by elinzeyjr »

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.
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

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.
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
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

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
elinzeyjr
Participant
Posts: 9
Joined: Thu May 11, 2017 9:18 am

Post by elinzeyjr »

FranklinE, you hit the nail on the head. Switched it to big-endian and it is now translating the COMP field as expected.

Thanks Again for your help.
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

Craig,

One can interpret "hexadecimal" to mean "curse the ten". :lol:

Anyway, I'm glad there's a good endian to this story. :wink:
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
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Ah... nothing like old mainframe developer humor. :D
-craig

"You can never have too many knives" -- Logan Nine Fingers
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

The Dad Jokes of the computer industry. I have a wonderful collection of them.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

C:/DOS
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
UCDI
Premium Member
Premium Member
Posts: 383
Joined: Mon Mar 21, 2016 2:00 pm

Post by UCDI »

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.
Post Reply