Hi,
I am facing some difficulty while doing division operation using DFSORT. I have to calculate the percentage rate. My input looks like as below, and it is an FB file (80 LRECL)
| Match Rate 6.35964 | AAAAAAAA
| Match Rate 20.00000 | BBBBBBBB
| Match Rate 100.00000 | CCCCCCCC
| Match Rate 84.92361 | DDDDDDDD
| Match Rate 0.00000 | EEEEEEEE
| Match Rate 96.90605 | FFFFFFFF
| Match Rate 0.59204 | GGGGGGGG
I have used the following SORT to generate the output. It is working fine with all records except for ‘EEEEEEEE’ record, because of all zeroes in the 11 position to 19 position. And I am getting an OUTREC ARITHMETIC OVERFLOW error message. So Please provide me a solution to overcome this problem.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Actually, when I ran this job with DFSORT's ICETOOL, it did not get any error message and produced this output:
Code:
| MATCH RATE 6.35964 | AAAAAAAA
| MATCH RATE 20.00000 | BBBBBBBB
| MATCH RATE 100.00000 | CCCCCCCC
| MATCH RATE 84.92361 | DDDDDDDD
| MATCH RATE 0.00000 | EEEEEEEE
| MATCH RATE 96.90605 | FFFFFFFF
| MATCH RATE 0.59204 | GGGGGGGG
Since you have PGM=SYNCTOOL, it appears you're actually using Syncsort's SYNCTOOL rather than DFSORT's ICETOOL. Syncsort is getting the error message, not DFSORT.
I'm a DFSORT developer. DFSORT and Syncsort are competitive products. I'm happy to answer questions on DFSORT and DFSORT's ICETOOL, but I don't answer questions on Syncsort.
Joined: 25 Jun 2007 Posts: 196 Location: Bangalore
surendra_giddaluru,
I tried with your code and input posted by you with SYNCSORT. It shows the output as FRANK's posted.
Quote:
And I am getting an OUTREC ARITHMETIC OVERFLOW error message.
I got the "OUTREC ARITHMETIC OVERFLOW error message" when i tried to divide a number by zero.
Please check with your input whether you have zeros in 25,9.
Use SYNCSORT instead of SYNCTOOL and reformat the fields in INREC for your requirement. It will be more efficient when doing a run with large number of records.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
******************************** Top of Data ***********************************
| MATCH RATE 6.35964 | AAAAAAAA
| MATCH RATE 20.00000 | BBBBBBBB
| MATCH RATE 100.00000 | CCCCCCCC
| MATCH RATE 84.92361 | DDDDDDDD
| MATCH RATE 0.00000 | EEEEEEEE
| MATCH RATE 96.90605 | FFFFFFFF
| MATCH RATE 0.59204 | GGGGGGGG
******************************* Bottom of Data ********************************
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
It is also possible that your version of Syncsort is either not up to date or missing some fix(es). I'd suggest opening an issue with Syncsort support to determine why your process did not work correctly.
As suggested, make sure that the input is what it should be.
Hi Frank and Sankar thanks a lot for your suggestions. I tried with SYNCTOOL and SYSNSORT both are working fine, thanks. I have one more issue. My input file will sometimes have all zeroes in both (11,9) and (25,9) positions. I tried using SYNCTOOL and SYNCSORT both the times it got abended with 'ARITHMETIC OVERFLOW' error message. The input I used is as below. Please provide me with some solution.
I am rewriting a COBOL program which is currently running for a long time. So now I am doing file processing in the COBOL program and for generating the report, which needs to sum the individual accounts and also needs to calculate the percentage match rate for each account, I am using the SORT. So in my old COBOL program when ever the values in (11,9) and (25,9) positions are zeroes we are moving 0.0000 to the Match Rate without doing any division operation for that perticular account.
Now I think we need to verify these values before calculating the match Rate. Atleast the values in (25,9) position, so that the SORT will not fail. If the values in (25,9) position is zeroes I need to move 0.0000 explicitly without doing the division operation for calculating the Match Rate. Hope I am clear this time.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Helllo,
Quote:
I am rewriting a COBOL program which is currently running for a long time.
How many records are being processed? How long is a "long time"?
What does this COBOL code do that the sort does not do or does differently?
If the code is to read the file and create summary statistics, i believe they should run a similar length of time. The COBOL code may use a bit more cpu, but wall-time should be quite similar as most of the time should be spent doing i/o.
I don't know how to tell Syncsort to conditionally bypass the calculation.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Don't tag a new question onto the end of an old topic.
A packed-decimal field on a file has no decimal places, implicit or explicit. You don't have to convert your data. When you define your field in your code, define with the decimal places and everything will be fine (from your example).
With your parameters you are making it 100 times too small, because you are dividing by 100. Leave it alone.
Why is your field unsigned (F in the sign nibble, not C for positive (or D for negative))? If this is correct, make sure you define your data as unsigned as well as having the two decimal places.
.jpg)
