comp 2 3

[andymc1]

Hi

am dealing with a rewrite of a module which uses comp 2 fields. From IBM it would seem these can contain either 18 or 31 digits but how do you know how many decimal places there are? Also if I wanted to split the comp 2 field into two fields i.e. ws-integer ws-decimal whats the best way of doing it

thanks
Andy

 

[3gm]

Andy -

COMP-2 is an IBM extension to COBOL. Items described as COMP-2 have no PICTURE clause and are stored as double precision floating-point items. They occupy 8 bytes of storage. Floating-point numbers don't have decimal places in the traditional sense. They are stored as an exponent and a mantissa (remember scientific notation from your math or science classes?).

To extract the whole number part of one of these, simply move it to a field that is numeric or numeric-edited and that doesn't have any decimal places defined, e.g. "PIC 999999". Same thing for the fractional part, move it to a field that has no digits defined to the left of the implied or actual decimal point, e.g. "PIC v999999".

Regards.

Glenn

 

[PHV]

You can try something like this:
01 ws-comp2 COMP-2.
01 ws-float PIC 9(9)V9(5).
01 filler redefines ws-float.
03 ws-integer PIC 9(9).
03 ws-decimal PIC 9(5).
and then MOVE ws-comp2 TO ws-float will do the trick.
But be aware that floating point items may be very huge

Hope This Help, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884

 

[k5tm]

Andy,

As Glenn has pointed out, COMP-2 floating point numbers may represent numbers whose absolute value are extremely large or extremely small. The original programmer may have chosen COMP-2 because[ul][li]he didn't know better (floating point easily can produce inexact results which are unwelcome in most accounting applications), or[/li][li]because he knew something about the possible range of data values that would indicate the need for COMP-2's large dynamic range (for which standard COBOL data types offer little help).[/li][/ul]

So, other than knowing that the data are in COMP-2 format, what else do you know about the data?

Tom Morrison

http://www.liant.com

 

[WMK]

Depending upon what you are doing with the "result" - you may want to "extract" your (IBM) internal floating-point item to an external floating point item, e.g.

05  Internal-FP   Comp-2.
05  Ext-FP   +9.9(15)E99.
  ...
Move Internal-FP to Ext-FP

Bill Klein

 

[andymc1]

The data is used for policy calculations which can be a large number but I wouldn't have said huge. Also they would run to a few decimal places but it doesn't appear to warrant a comp-2 field. When calculations are done in the original module, they are exactly as Glen and PHV suggested above.

I think comp-2 is unnecessary in this case and for ease of readability, as well as to align this module with every other in the system it would be better having packed decimal, but part of my remit is to get exactly the same figures as the original module, therefore I have coded (against my better judgement) using comp-2. But then again as its the first time I have encountered this type of issue I'm bound to be a little sceptical and probably will be until I get the time to play about with it. Thanks for all of your replies.

Andy

 

[k5tm]

Andy,

As you have been challenged to obtain identical results, when you convert to packed decimal it is best that you carry an excessive amount of decimal accuracy and then judiciously use ROUNDED. If you are on a compiler that supports more than 18 digits, try something like MOVEing to an item with PIC 9(15)v9(15). This should get you enough decimal digits that you will get identical results in the downstream calculation.

If you get too much harrassment for being unable to obtain identical results with exact decimal arithmetic, point out to your detractors that COMP-2 cannot represent 0.01 exactly!

Tom Morrison

http://www.liant.com

 

[WMK]

If one is talking about floating-point and rounded in the same context, you need to be VERY careful about what your specific vendor says on this subject. For example, IBM at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr20/6.1.8.3

says,

"In a floating-point arithmetic operation, the ROUNDED phrase has no effect; the result of a floating-point operation is always rounded. For more information on floating-point arithmetic expressions, see the Enterprise COBOL Programming Guide."

P.S. It is also true that (for IBM) using floating-point numbers may or may not give you the "right" answers - so if you are asked to get "identical" answers, this may be a challenge. HOWEVER, in an application "interacting" with other applications/languages (such as C) the use of floating-point may be required.

Bill Klein

 

[Dimandja]

Another insightful post, WMK.

 

[k5tm]

Bill,

My comment regarding ROUNDED was not in the context of floating point (which can either be viewed as always rounded, or perhaps always slightly wrong), but rather in the context of converting the application to use packed decimal. In that context I recommended more precision than might otherwise be deemed necessary and judicious use of rounding so that identical results (to the COMP-2 implementation) might be obtained.

Okay, now I feel better.

BTW, you might be able to discern that I view floating point computations with some skepticism. I have done a couple floating point emulators in my career. I knew that when my first IBM FP emulator produced 2 * 2 = 16 that it was ready!

Tom Morrison

http://www.liant.com