Packed decimal

boris · Post by **boris** » Fri Jul 16, 2004 8:21 am

Hi all,
we are getting a file (packed decimal) from DB2 and we are trying to put it in a flat file.Iam using CFF stage here and its taking the record layout correctly but somehow nummerics are getting changed.

2.0200,2.0260,20.200 should actually be
0.0000,0.0500,00.000

Any clues what has to be done??
Thanks
Boris

roy · Post by **roy** » Sun Jul 18, 2004 12:38 pm

Hi,
at first look this sounds like a platform difference issue.
what exactly is your DB2 platform, could it be that your DB platform stores data in another fasion then your DS (windows) platform (like the way numbers consisting of several bytes are stored) ?
if so how do you connect to your DB?
this is all assumptions, we really need more info regarding your configuration and what your doing to try and point out the cause.

IHTH,

boris · Post by **boris** » Thu Jul 22, 2004 11:38 am

Hi Roy,
We are getting Data from DB2 Ftp ed to us in Binary format.The thing is while using CFF stage its picking up the correct layout and most of the data is correct except in few columns. Could that be a problem with the data ????
The data we are getting is this way
"+,+,+,+,+,+,+,+,+,+,+,+,"

These are the values that should be transferred from the mainframe. The actual data.
+0,+0,+0,+25.580,+0,+00.370,+0.0500,+27.562,+0,+0,+.025,+0.9600

Any clues or any steps to be taken??
thanks
Boris

crouse · Post by **crouse** » Thu Jul 22, 2004 11:54 am

Do you have COBOL FD (File Definition) that matches the file layout you are getting DB2? Also, is DB2 on an MVS mainframe or AS/400?

Sounds like the table def in DataStage (and used by the CFF) doesn't understand HOW the data is packed (COMP? COMP-3?). That is specified in the COBOL FD, or something, from the data source...

If you have the COBOL FD, paste a section of it here, relative to the columns that are messing up.

Thanks,
Craig

boris · Post by **boris** » Thu Jul 22, 2004 12:26 pm

Hi Craig,
Its the Mainframe environment and there are like 50 colms but we are getting the prob particularly in these fields.

The layout for the rates portion of the record is as follows:
EMP-IWDP-HRS-AVBL S9(4)V9(1)
EMP-VACA-HRS-AVBL S9(4)V9(1)
EMP-HOLI-HRS-AVBL S9(4)V9(1)
EMP-BASE-RATE S9(2)V9(3)
EMP-BASE-PAY-AMT S9(13)V9(2)
EMP-COLA-RATE S9(2)V9(3)
EMP-SHIFT-PREM-PCT S9(1)V9(4)
EMP-VACA-RATE S9(2)V9(3)

thanks
Boris

inter5566 · Post by **inter5566** » Thu Jul 22, 2004 1:52 pm

Boris,

This definition is not for packed decimal or even binary. The data on the mainframe should look a little strange when you look at it in an edit session. For example, the actual value +1215 would look something like 121* ( the * may be some other character depending on the opnes position ). This is either zoned numeric or signed numeric, can't remember for sure. You need to turn on the hex display mode while looking at the mainframe data and let us know what you see. If you want to look at the data on your windows platform after the binary transfer, you will need some type of hex editor which will not try to convert everything into ASCII.

HTH,
Steve

boris · Post by **boris** » Thu Jul 22, 2004 2:01 pm

Hi Steve
What funtion is best to use here in this case??

EMPID
018381688
packed fields in Hex format 0000000002800000000003005025200000506000F00F00F58F0000000F07F00F76F0C0C2C90F

Packed fields equivalent
+0,+0,+0,+25.580,+0,+00.370,+0.0500,+27.562,+0,+0,+.025,+0.9600
thanks
Boris

inter5566 · Post by **inter5566** » Thu Jul 22, 2004 2:25 pm

Boris,

I'm not following your "packed fields in hex format" line. How are you looking at the mainframe data? If you are using ISPF edit, then you need to enter "hex on" at the command line to see the hex representation of the data. Should look something like this:

Code: Select all

121*....256<....      This is the EBCDIC character representation of the data
FFF50000FFF40000      The last two lines are the hex representation of the 
121C000C256C000C      data read vertically. i.e  1 in character = F1 in hex

the data values represented above are 1215,0000,2564,0000.
The sign is incorporated into the representation of the last digit, C for positive and D for negative.

I'm sure glad memory is cheap now a days, getting a headache thinking about this

Maybe we will only have to deal with issues like this for another 30 or 40 years

HTH,
Steve

crouse · Post by **crouse** » Thu Jul 22, 2004 2:32 pm

In your CFF stage, how have you defined the "Data Format"? ASCII or EBCDIC? (Looks like) it needs to be EBCDIC.