Calculation on 2 numeric fields of 18 digits

[NewItron]

Hi,
I know there has been a similiar thread on this forum but I am not able to trace it.
The problem is:
How do we do calculations(add,subtract,multiply,divide) on 2 numbers of 18 digits each.

Thanks and Regards
Tushar

 

[fredericofonseca]

01 f1 pic 9(18).
01 f2 pic 9(18).
01 f3 pic 9(18).

...

add f1 to f2 giving f3
add f1 to f2
divide f1 by f2 giving f3
and so on.

To test for an possible error on the size of the resulting/intermediary field look for the "on overflow" option of the operations above. Your COBOL manual will have this info.


If you with to ahve the fields bigger than 18 then you have a problem if your compiler does not support them, so please make sure of what your question really is.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[WMK]

Actually, this is a case where I would (normally) recommend COMPUTE over the ADD, SUBTRACT, etc statements.

The COMPUTE statement removes the restriction on "composite of operands" that may exist using the individual statements.

ON THE OTHER HAND, you need to understand what your specific compiler does with "intermediate results" when you use the COMPUTE statement. Otherwise, you may get VERY unexpected results!

Bill Klein

 

[k5tm]

Tushar,

You didn't tell us the brand of compiler, etc. Many (most/all?) modern releases of COBOL compilers support more than 18 decimal digits, e.g. [tt]PIC 9(20)[/tt].

If it is your intention to use two 18-digit operands and store in an 18-digit result, definitely use the [tt]ON SIZE ERROR[/tt] clause.

Tom Morrison

http://www.liant.com

 

[TysonLPrice]

If you're using OS/390 COBOL 2.2.1 or greater (including Enterprise), use the compiler option ARITH(EXTEND), which allows a picture clause size up to 31.

 

[WMK]

The IBM compiler option

ARITH(EXTEND)

is well documented as being HORRIBLE (well at least "poor") for performance. See, for example,

http://www-1.ibm.com/support/docview.wss?uid=swg27001475&aid=2

Bill Klein

 

[k5tm]

But we are all talking to thin air, because Tushar is gone, gone, gone...

Tom Morrison

http://www.liant.com

 

[TysonLPrice]

is well documented as being HORRIBLE (well at least "poor") for performance. See, for example,

I couldn't open that document. I also couldn't find any links on it being "HORRIBLE (well at least "poor") for performance". I did see some mention performance degradation but that also depended on what tuning efforts were made for it.

 

[ceh4702]

The Compute verb has some tools for indicating if there is an overflow condition.

However, where do you put the result when it will not fit in the largest possible variable?

Outside of exponential notation the operation is impossible to complete using a normal mathematical operation.

It is possible to handle numbers as text or a table and perform the operation one column at a time and store it as text one colum at a time. I use to have a program like this for my calculator that could divide numbers and store the values as text and control how long you wanted the operation to continue. It would take a little work to get something like this to work.

If you do not like my post feel free to point out your opinion or my errors.

 

[k5tm]

However, where do you put the result when it will not fit in the largest possible variable?

One way is to scale the input operands, perhaps through redefinition, so that, rather than the result conceptually requiring [tt]9(36)[/tt], it instead requires [tt]9(18)v9(18)[/tt]. Then one stores the result in both a [tt]9(18)[/tt] and a [tt]V9(18)[/tt] result to capture all the digits.

But, as I said before, most, if not all, modern compilers will handle a substantial number of digits.

Tom Morrison

http://www.liant.com