ONCODE 310 FIXED DECIMAL OVERFLOW

swathykrishnan · New User Joined: 01 Oct 2010 Posts: 43 Location: Bangalore

Hi

I have 3 variables with the definition given below

A FIXED BIN(15,2)
B FIXED BIN(15,2)
C FIXED BIN(5,2)

And the the following operation will be performed on these variables

A=ROUND((B * (ROUND(PREC(C/100.5,4),3)),2)

This code will give ONCODE 310 when B is having 13 digits in integer part. It will work fine till B is having 12 digits in integer part. We can use MULTIPLY function to avoid this issue. But it will cause truncation of decimal fields. Is there any other way to fix this issue?

Bill Woodger · Posted: Mon Sep 12, 2011 11:50 am

I don't think you have fully described your problem.

If the sub-calculation of C, for instance, returns a value of 1, are you saying you'd get an error with B having 13 digits before the decimal place?

swathykrishnan · New User Joined: 01 Oct 2010 Posts: 43 Location: Bangalore

Hi Bill

The value of C will be always always <=100. If its sub calculation gives 1 it wont create any issues. Say value of C as 12.55 and B=9874567654321.88 the program will abend with ONCODE 310.

Bill Woodger · Posted: Mon Sep 12, 2011 12:33 pm

So, if you, in your data definition, have a maximum of 13 positions before the decimal place, and you have a 13 non-decimal-digit number, and you multiply by 10, you get 14 digits, which don't fit, so POP.

You definition should be made big enough to contain the maximum value that is reasonable for the program to handle.

prino · Posted: Mon Sep 12, 2011 8:31 pm

You do not, EVER, use "fixed bin (15,2)" variables in PL/I.

If you want to use fractions in PL/I you use FIXED DEC!

Given the numbers you post, 9874567654321.88 and 12.55, you also don't have a clue as to what a "fixed bin (15,2)" actually means, as neither of them can ever be stored into a variable of that type and precision.

dbzTHEdinosauer · Posted: Mon Sep 12, 2011 9:36 pm

you don't do it with cobol either.

lot of knuckleheads think binary computations are faster,
(even though z/os has hardware / middleware / decimal functions)
and all the bytes you can save with binary fields.

a lot of misconceptions and little understanding lead to problems like the ts has posted.

did the rastelle thumb a few years ago. did not know that it was you.

Akatsukami · Posted: Mon Sep 12, 2011 9:55 pm

swathykrishnan · New User Joined: 01 Oct 2010 Posts: 43 Location: Bangalore

Hi Prino.

That was a mistake from my side.. I am using FIXED DEC only...

Bill Woodger · Posted: Tue Sep 13, 2011 12:37 pm

Presumably PL/I has an equivalent to Cobol's ARITH(31) compiler option, if your problem is a plain lack of digits.

Unrelated, but with A being such a vast number, are you really sure your user is worried about +/- .01 from the final rounding?

It is unusual to me to see the rounding of the intermediate products. If that is what the user wants, OK.

prino · Posted: Tue Sep 13, 2011 1:20 pm

swathykrishnan · New User Joined: 01 Oct 2010 Posts: 43 Location: Bangalore

Hi Bill

Yes the user need it to get rounded for 2 digits even if its a vast number...
MULTIPLY or FLOAT DECIMAL will fix this issue... But we need to ROUND it...

Bill Woodger · Posted: Tue Sep 13, 2011 3:22 pm

Hi,

Did you see Prino's last post? If you need more digits than you are "allowed", use the compiler option he has posted to give yourself access to more digits. Then you can define your fields as big enough for your purposes, and ROUND it to your heart's content.