I have used the parm of OVRFLO=RC4 to bypass the overflow error, but that has not helped.
Also, I have read in one of the tutorials that 'If an intermediate or final result of an arithmetic expression overflows 15 digits, the overflowing intermediate or final result will be truncated to 15 digits'. If this is the case, then why does the overflow error occur?
Is there any other way through which I can divide the SFF values by preventing the overflow? Or do I need to convert them to ZD before dividing?
I have tried the same job in one of my friend's organization which has DFSORT installed. According to him even he is facing the same overflow error at his site.
Meanwhile, I have dropped a mail to 'zos_tech@syncsort.com' requesting for SYNCSORT manuals. I have provided them with the license number and my organization details as well.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Does the overflow occur on the first record processed or have some records processed before the problem occurs? A divide by zero would always generate an overflow, would it not?
Also, when i divide/multiply the numbers you posted using the calculator on my pc, i get 0.1150089715402809 . . .
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If you have such huge numbers, I'd do the calculation in a programming language you are familiar with so that you can get the correct results within the parameters of the calculation.
I don't know what Synsort does, but, like Dick, I did the calculation on a PC and it came up with loads more than 15 digits, not necessarily relevant as you don't have the documentation for your product yet.
Also check on the rounding done by Syncsort, when you can.
If you think it might be to do with the SFF, which don't you try converting and see if anything changes?
Obviously verify (by "printing" them to sysout from the Sort) the values in the positions/lengths you are using.
When having the (* 100) I was always told to do it first. With big numbers you can loose significance at the right of the result.
The above problem has been solved, as mentioned by Dick, there was indeed value 0 in the second file, which during division was causing the Overflow error.
One more doubt for the same problem, in my input files I have such values in 26 columns, for which I need to perform the division in the same way as mentioned above. Now in order to by-pass the conidtion of having 0 in the columns of the second file, I am making use of IFTHEN and WHEN parameters. The problem here is, I am using around 26 IFTHEN and WHEN parameters, out of which only 2 are getting executed. For example,
File 1 looks like, values start from 24 and 45
Code:
----+----1----+----2----+----3----+----4----+----5----+----6----+
********************************* Top of Data *******************
1001695001 2 20120323 +00000000000008565.8 +00000000000012372.8
1001950001 2 20120323 +00000000000000000.0 +00000000000000000.0
1001978002 2 20120323 +00000000000000000.0 +00000000000000000.0
1002317001 2 20120323 +00000000000000000.0 +00000000000000113.8
File 2 looks like,values start from 613 and 634
Code:
9----+----0----+----1----+----2----+----3----+----4----+----5----
********************************* Top of Data *******************
1001695001 2 20120316 +00000000007447940.7 +00000000008149379.6
1001950001 2 20120316 +00000000000012992.0 +00000000000005504.0
1001978002 2 20120316 +00000000000000000.0 +00000000000000480.0
1002317001 2 20120316 +00000000000043013.9 +00000000000061846.3
Please note here that I have joined these 2 files using join keys and the record length of each file is 589, format FB.
For the second IFTHEN to operate when the first is true for that record, you need HIT=NEXT where I have put the £. Same thing with the third and second.
That's how DFSORT does it, anyway.
EDIT: Remember to check in the documentation, when you get it, how the rounding is done.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Well I stopped looking when I saw the HIT=NEXT missing.
Have a close read in the manual of the way BUILD works. Bear in mind what your data is showing you. Do some other "experiments". Continue until you fully understand what happens when you do more than one BUILD on the same record.
Then consider how to use OVERLAY for your purpose.