DSXchange

Hello -

I am having an issue with packed decimals in the CFF Stage.

First here is some background on the job design:
- Bring fixed length records in via Seq. File Stage
- Parse records based on byte order
- Sort records
- Pack records in the CFF Stage

Issue:
- The only fields I am having issues with are ones which are signed.
For example... I have an amount field which is a PIC S9(13)V9(2) COMP-3 (15 length 2 scale)
- In the source data this column equals 100600
- However, when I pack this column and view the data in the CFF is looks like 100600.00 when it should be 1006.00

Any advise is appreciated.
Thanks -
Jared

What does the actual output file look like, as seen from a tool other than view data in the CFF stage? You might be seeing an issue using view data rather than a problem in your output file. You could write a small job to read the packed data to see if the assumed decimal position is in the correct location.

ArndW:

The packed output file is being sent to a mainframe program. I have been working with the mainframe team throughout the development. A member of the mainframe team made me aware to this decimal location issue.

From what you said, it sounds like the assumed decimal position is off.

Does the metadata on the Columns grid specify scale = 2?

Ray -

Here are what the column grid fields contain:

Level Number = 2
Column Name = Amt
Native Type = Decimal
Extended =
Length= 15
Scale = 2
Nls Map =

This is a signed field so the picture clause = PIC S9(13)V9(2) COMP-3.

Is there something under the extended attributes section which I should be using?

Thanks,
Jared

All -

I did some research and found the OCONV conversion.

However, when i go to use it in the Transformer Stage it does not work. Shows up as a red error when I leave the derivation box.

Ex. OCONV(DOC_AMT,"MD22")

The "DOC_AMT" field is a decimal, length 15 scale 2.

Please advise,

Thanks.

It's a BASIC Server function so not valid in a Parallel job unless you use it from the BASIC Transformer and understand all that brings along with it.

jzajde1 wrote:In the source data this column equals 100600

In other words 100600.00 is what it sees coming in. And then you "pack it" and you end up with exactly the same output (as you should) - essentially it writes it out with the assumed decimal removed, i.e. as 10060000 which is why the View Data shows it to you as 100600.00 when it descales it to put back the explicit decimal point that is not being stored. You need to present the proper value to it to "pack" so it knows where the decimal point really is. With your amounts coming in as they are, divide the amount by 100 before you send it to the CFF for packing.

That's my take on the issue.

Craig -

I did read this on another thread, and it is working to an extent.

However, it doe not work when there are cents involved.

Ex. 1015.00 should be 10.15
This value shows up as 10.00 once I divide 1015.00 by 100

Then you've defined the target data type incorrectly. Should be a decimal with the proper precision and it sounds like you've got it defined as an integer.

The field is defined as a decimal across the 2 remaining stages (Sort & CFF).

** I did notice something interesting though. I removed the amount field in the CFF Stage (which is the final stage in the program). Then I put it back into the CFF stage. Once I carried it over from the sort, I noticed that the Native Type in the CFF was Group instead of Decimal. The scale was also removed.

Could this be the issue

Me? No clue and no way to get one.

What about the definition of the field where you do the math? While the 'remaining stages' are important as well, so is the place (transformer, I assume) where the division is done.

Craig -

Got it!

In the transformer stage I was using Div(Amount,100).
I switched it to (Amount/100) and it worked!

Thanks for your help,

Jared

Right... that function doesn't do "full" division but only returns the quotient, an integer value. That's also why the documentation says that if you want to know the remainder to use the Mod function. Functions like that are generally for specialty situations, if you just want to do "math math" stick with the arithmetic operators.

Thank you for the advice! I will be sure to follow it in the future designs.

Regards,
Jared