When will we go for comp and when will we go for comp3

vamsi1978 · New User Joined: 04 Apr 2007 Posts: 3 Location: Channai

hi Guys

when will we go for comp and when will we go for comp3

monga · New User Joined: 18 Apr 2006 Posts: 13

COMP is BINARY format.It is suitable for subscripts and arithmetic operands or results.

COMP-3 is floating point format (used for handling floating point values)

Thanks,

monga

venosol · New User Joined: 16 Nov 2006 Posts: 43 Location: Bangalore

agkshirsagar · Posted: Thu Apr 05, 2007 12:09 pm

monga · New User Joined: 18 Apr 2006 Posts: 13

Yup...the correct statement would be that COMP-3 is for packed decimal items (floating point if COMP-1 and 2).

Thanks,

monga

P.S: this is from the IBM COBOL program guide

rashmik · New User Joined: 09 Mar 2007 Posts: 2 Location: mysore

hi

normally it is saying that comp-3 is better than comp usage. but comp usage performs well at the boundaries.
as
we know that
comp(1-4) = 2 bytes
comp(5-9) = 4 bytes
comp(10-18) = 8 bytes etc

if our variale is having 4 digits, 9 digits.etc.. comp is good
eg
01 var1 s9(04) comp.
01 var2 s9(04) comp-3.

then for storing var1 2 bytes will take, but for var2 3 bytes will take 1 for sign

TG Murphy · Posted: Sat Apr 07, 2007 4:59 am

COMP-3 is typically used to store money amounts (ie 123.45) or rates (ie. .0675).

COMP is typically used to store integers including subscripts, counts, id numbers.

COMP-3 can produce a data exception. COMP will never produce a data exception. COMP uses the least amount of storage.

William Thompson · Posted: Sat Apr 07, 2007 5:25 am

dick scherrer · Posted: Sat Apr 07, 2007 6:12 am

Hello,

Because of the need to make things like money, quantities, counts, etc visable (and provide better performance), they are most often stored and accumulated in packed-decimal (comp-3) fields (not any other format). Many sites have standards that this is mandatory and will not promote the code to production until the stardard is followed.

Reasons for this are consistency and performance (the packed-decimal instructions perform well). Also, space is not really an issue. A big reason to use comp-3 fields for numbers that must be seen by people is that in order to "edit" them with a pattern (i.e. $12,321.65) is they they must be converted to packed-decimal for the assembler instruction to create the visable output. If there are binary or zoned decimal numbers there is extra overhead converting the number to comp-3 internally.

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

There are a lot of if/ands & buts surrounding this issue. The link below points to an IBM White Paper on preformance. Page 31 - Comparing Data Types gives a good insight into the complexities involved.

5/27
Sorry - the link got lost and I couldn't find the site again. But I did find this in an old file (written by Bill Klein):

***********************************************************************
Performance Comparison of COMP/COMP-3 Arithmetic
***********************************************************************
On the IBM mainframes, COMP is much faster than COMP-3 up through 9
digits. After 9 digits, COMP fields are processed with a subroutine,
which is very much slower." That is true when TRUNC(OPT) is used.
If, however, TRUNC(BIN) (for example) is used, the following is from
the Enterprise COBOL V3R1 "performance tuning" paper,"Comparing Data
Types" When selecting your data types, it is important to understand
the performance characteristics of them before you use them. Shown
below are some performance considerations of doing several ADDs and
SUBTRACTs on the various data types of the specified precision.

Performance considerations for comparing data types (using ARITH(COMPAT)):

Packed decimal (COMP-3) compared to binary (COMP or COMP-4) with
TRUNC(STD)

using 1 to 9 digits: packed decimal is 30% to 60% slower than binary
using 10 to 17 digits: packed decimal is 55% to 65% faster than binary
using 18 digits: packed decimal is 74% faster than binary Packed
decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(OPT)
using 1 to 8 digits: packed decimal is 160% to 200% slower than binary
using 9 digits: packed decimal is 60% slower than binary
using 10 to 17 digits: packed decimal is 150 to 180% slower than binary
using 18 digits: packed decimal is 74% faster than binary Packed
decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(BIN)
or COMP-5
using 1 to 8 digits: packed decimal is 130% to 200% slower than binary
using 9 digits: packed decimal is 85% slower than binary
using 10 to 18 digits: packed decimal is 88% faster than binary
using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed decimal
using 17 to 18 digits: DISPLAY is 150 to 200% slower than packed decimal
DISPLAY compared to binary (COMP or COMP-4) with
TRUNC(STD)
using 1 to 8 digits: DISPLAY is 150% slower than binary
using 9 digits: DISPLAY is 125% slower than binary
using 10 to 16 digits: DISPLAY is 20% faster than binary
using 17 digits: DISPLAY is 8% slower than binary
using 18 digits: DISPLAY is 25% faster than binary
DISPLAY compared to binary (COMP or COMP-4) with
TRUNC(OPT)
using 1 to 8 digits: DISPLAY is 350% slower than binary
using 9 digits: DISPLAY is 225% slower than binary
using 10 to 16 digits: DISPLAY is 380% slower than binary
using 17 digits: DISPLAY is 580% slower than binary
using 18 digits: DISPLAY is 35% faster than binary
DISPLAY compared to binary (COMP or COMP-4) with
TRUNC(BIN) or COMP-5
using 1 to 4 digits: DISPLAY is 400% to 440% slower than binary
using 5 to 9 digits: DISPLAY is 240% to 280% slower than binary
using 10 to 18 digits: DISPLAY is 70% to 80% faster than binary

Bill Klein

vamsi1978 · New User Joined: 04 Apr 2007 Posts: 3 Location: Channai

tnaks 2 all for u r valuable inf..

TG Murphy · Posted: Fri May 11, 2007 11:44 pm

William,

You said "And that makes it safe? Garbage is garbage....Packed or binary...Garbage is garbage"

I agree 100%. I wasn't clear about that at all.

The most experienced COBOL programmer in our shop (recently retired) would often encourage the use of COMP-3 because it was safer.

Scenario: Your storage gets clobbered by garbage. If this happens, a COMP-3 field will trigger an abend. Which is exactly what you want. COMP will not do that and as you say, this is a bad thing. If it doesn't abend, then perhaps the database gets updated with junk...

[/quote]

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

Hi All,

Way back on April 7th I said I included a link address that explained the peformance complexities involved when comparing COMP arith to COMP-3.

Unfortunately I dropped the link. I finally found a replacement (written by Bill Klein) and updated my original post above if anybody's still interested.

Sorry for the mix-up and

dr_te_z · Posted: Mon Jun 18, 2007 11:15 am

One thing I'd like to add to this topic:
COBOL programmers sometimes get assignments for COBOL on the PC or Unix. If so: forget about COMP-3! This is a typical mainframe format.

The compiler will understand and execute, but performance is really bad because the CPU will not support that format as mainframe CPU's do.
Rather use "COMP-5" (=binary native).

N.B.

When you have to store numeric data in a file (FD) then you could still concider COMP-3. It is effeciently compressed and you do not have to worry about big-endian formats, these tend to differ on PC/unix architectures.