Packed Decimal Issue
Moderators: chulett, rschirm, roy
Packed Decimal Issue
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
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.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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
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
Re: Packed Decimal Issue
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.jzajde1 wrote:In the source data this column equals 100600
That's my take on the issue.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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
** 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
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.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers