Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

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

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
vamsi1978

New User


Joined: 04 Apr 2007
Posts: 3
Location: Channai

PostPosted: Thu Apr 05, 2007 11:19 am    Post subject: When will we go for comp and when will we go for comp3
Reply with quote

hi Guys

when will we go for comp and when will we go for comp3
Back to top
View user's profile Send private message

monga

New User


Joined: 18 Apr 2006
Posts: 13

PostPosted: Thu Apr 05, 2007 11:33 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
venosol
Warnings : 1

New User


Joined: 16 Nov 2006
Posts: 43
Location: Bangalore

PostPosted: Thu Apr 05, 2007 11:48 am    Post subject:
Reply with quote

monga wrote:
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


COMP is used for storing big values.

COMP-3 is used in calculations only
Back to top
View user's profile Send private message
agkshirsagar

Active Member


Joined: 27 Feb 2007
Posts: 686
Location: Earth

PostPosted: Thu Apr 05, 2007 12:09 pm    Post subject:
Reply with quote

Quote:
COMP-3 is floating point format

Not correct.
Quote:
COMP is used for storing big values.

COMP-3 is used in calculations only

Not correct/clear either.
Instead I would suggest referring manual and find out yourself.
Or search on forum, you will get much more thank you wanted.
Back to top
View user's profile Send private message
monga

New User


Joined: 18 Apr 2006
Posts: 13

PostPosted: Thu Apr 05, 2007 12:29 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
rashmik

New User


Joined: 09 Mar 2007
Posts: 2
Location: mysore

PostPosted: Thu Apr 05, 2007 6:41 pm    Post subject: Re: When will we go for comp and when will we go for comp3
Reply with quote

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
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 149
Location: Ottawa Canada

PostPosted: Sat Apr 07, 2007 4:59 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

PostPosted: Sat Apr 07, 2007 5:25 am    Post subject:
Reply with quote

TG Murphy wrote:
COMP will never produce a data exception.
And that makes it safe? icon_rolleyes.gif Garbage is garbage....Packed or binary...Garbage is garbage
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sat Apr 07, 2007 6:12 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Sun Apr 08, 2007 1:37 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
vamsi1978

New User


Joined: 04 Apr 2007
Posts: 3
Location: Channai

PostPosted: Fri May 11, 2007 5:27 pm    Post subject:
Reply with quote

tnaks 2 all for u r valuable inf..
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 149
Location: Ottawa Canada

PostPosted: Fri May 11, 2007 11:44 pm    Post subject:
Reply with quote

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]
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Sun May 27, 2007 7:49 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
dr_te_z

New User


Joined: 08 Jun 2007
Posts: 71
Location: Zoetermeer, the Netherlands

PostPosted: Mon Jun 18, 2007 11:15 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Protection Exception while move 0 to ... Kevin Vaz CICS 10 Tue Oct 18, 2016 4:19 pm
No new posts How can we create a flat file in JAVA... rakesh.v18 Java & MQSeries 7 Fri Sep 23, 2016 10:46 pm
No new posts Need help to populate date in COMP-3 ... chetanambi DFSORT/ICETOOL 3 Tue Jun 21, 2016 12:25 pm
No new posts comparing comp-3 and unpacked numbers juares castro COBOL Programming 3 Mon May 30, 2016 6:46 pm
No new posts SIGNED DECIMAL TO COMP-3 using cobol ... ram_vizag COBOL Programming 1 Tue Mar 01, 2016 11:32 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us