Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
When to use comp-3?
- Thread starter jeroldqc
- Start date
comp-3 is a way of compressing numeric fields into roughly half their size. I think the benefit comes the fact you don't have to use as much space for these types of fields. For example, if you have to add a field to an existing file and maybe there isn't much space left to play with.
Hope this helps....
Hope this helps....
Comp-3 is also used to avoid rounding issues that occur when binary numbers are used to represent decimal fractions. This is especially important in systems that process large volumes of financial transactions/amounts (e.g. banking, credit cards, etc.).
When you specify COMP-3 you are generally asking the compiler to implement any arithmetic operations as decimal arithmetic as opposed to using the binary arithmetic operations that are inherent in todays computers.
While it is possible to control the accuracy/precision of the decimal representation issue by careful programming, it is generally much simpler to just use binary-coded decimal (BCD) arithmetic by specifying COMP-3 fields. "Code what you mean,
and mean what you code"
Razalas
When you specify COMP-3 you are generally asking the compiler to implement any arithmetic operations as decimal arithmetic as opposed to using the binary arithmetic operations that are inherent in todays computers.
While it is possible to control the accuracy/precision of the decimal representation issue by careful programming, it is generally much simpler to just use binary-coded decimal (BCD) arithmetic by specifying COMP-3 fields. "Code what you mean,
and mean what you code"
Razalas
If I may invoke US Army Standard Answer #1 "It depends on the situation."
Warning: the performance of COMP-3 data varies greatly by architecture. My comments below reflect experience on IBM mainframes, HP minicomputers, and other systems that had direct support for COMP-3 fields. My comments may not apply to PCs and other systems.
I generally avoid COMP-3 fields in external files unless I have good reason to use them. Seems like someone is always wanting to copy those files to some other machine, etc, and dealing with COMP-3 data in those situations is problematic. A good reason to use them in an external file might be: (a) the field will be used for computation and (b) space in the record is at a premium due to some physical limitation and (c) the file is not likely to be used elsewhere.
Internally, I use COMP-3 for any field where there is substantial arithmetic combined with substantial movement of the field to/from a DISPLAY item. If the field is not used with DISPLAY items, it may best be COMP.
My rationale is based on how a DISPLAY NUMERIC field is handled in various situations. For example, to move it to a COMP field requires a PACK and a CVB instruction. To move a COMP field to a DISPLAY field requires a CVD and UNPACK. In each case, the intermediate result is a COMP-3 field. By using COMP-3 fields when DISPLAY NUMERIC fields provide/receive results, you avoid the extra conversions all the way to COMP.
Arguably, if you truly have a lot of arithmetic going on, COMP may be more efficient. You have to determine that in your own situation.
Glenn
Brainbench MVP for COBOL II
Warning: the performance of COMP-3 data varies greatly by architecture. My comments below reflect experience on IBM mainframes, HP minicomputers, and other systems that had direct support for COMP-3 fields. My comments may not apply to PCs and other systems.
I generally avoid COMP-3 fields in external files unless I have good reason to use them. Seems like someone is always wanting to copy those files to some other machine, etc, and dealing with COMP-3 data in those situations is problematic. A good reason to use them in an external file might be: (a) the field will be used for computation and (b) space in the record is at a premium due to some physical limitation and (c) the file is not likely to be used elsewhere.
Internally, I use COMP-3 for any field where there is substantial arithmetic combined with substantial movement of the field to/from a DISPLAY item. If the field is not used with DISPLAY items, it may best be COMP.
My rationale is based on how a DISPLAY NUMERIC field is handled in various situations. For example, to move it to a COMP field requires a PACK and a CVB instruction. To move a COMP field to a DISPLAY field requires a CVD and UNPACK. In each case, the intermediate result is a COMP-3 field. By using COMP-3 fields when DISPLAY NUMERIC fields provide/receive results, you avoid the extra conversions all the way to COMP.
Arguably, if you truly have a lot of arithmetic going on, COMP may be more efficient. You have to determine that in your own situation.
Glenn
Brainbench MVP for COBOL II
jetspin
Programmer
- Mar 5, 2002
- 76
- 0
- 0
Hi.
COMP-3 or "Packed Numeric" fields is a carry over from the days when only main frames existed and memory and disk space were very vital. If you think about it, one could almost save 1/2 the space if a record contain almost all numeric data.
A trick to use would be to define a group item with two fields in it defined as comp-3. You could then move the letter "j" for example to the group item name which would allow you to access the 'binary' portions of the ascii representation of the group item using the detailed comp-3 fields. We used to do this to define the escape sequences and any binary representation we needed. Today I think most cobol languages have other ways to do this.
COMP-3 or "Packed Numeric" fields is a carry over from the days when only main frames existed and memory and disk space were very vital. If you think about it, one could almost save 1/2 the space if a record contain almost all numeric data.
A trick to use would be to define a group item with two fields in it defined as comp-3. You could then move the letter "j" for example to the group item name which would allow you to access the 'binary' portions of the ascii representation of the group item using the detailed comp-3 fields. We used to do this to define the escape sequences and any binary representation we needed. Today I think most cobol languages have other ways to do this.
Hi,
On te IBM mainframe, the compiler will choose COMP-3 or PACKED-DECIMAL for intermediate results for a compute when the fields in the compute are not all COMP, COMP-4 or BINARY. By choosing COMP-3 yourself, you prevent conversion so the compute will be more efficient.
Only if the IBM mainframe compiler does not compile with option TRUNC(STD) - which is a bloody shame if any organization is using it - COMP, COMP-4 or BINARY computes will be faster, but only if the fieldtype COMP or BINARY is the only type used.
To avoid stupidity with TRUNC(STD) you can use COMP-5 instead of COMP or BINARY.
On the IBM BOOKMANAGER, you can find old optimizing guides, which can tell you what the performance differences are between fields.
IBM's BOOKMANAGER can be found at
I hope this is helpful.
Regards,
Crox
On te IBM mainframe, the compiler will choose COMP-3 or PACKED-DECIMAL for intermediate results for a compute when the fields in the compute are not all COMP, COMP-4 or BINARY. By choosing COMP-3 yourself, you prevent conversion so the compute will be more efficient.
Only if the IBM mainframe compiler does not compile with option TRUNC(STD) - which is a bloody shame if any organization is using it - COMP, COMP-4 or BINARY computes will be faster, but only if the fieldtype COMP or BINARY is the only type used.
To avoid stupidity with TRUNC(STD) you can use COMP-5 instead of COMP or BINARY.
On the IBM BOOKMANAGER, you can find old optimizing guides, which can tell you what the performance differences are between fields.
IBM's BOOKMANAGER can be found at
I hope this is helpful.
Regards,
Crox
On the IBM mainframe, COMP is faster than COMP-3 if all the fields are COMP and none are over 9 digits long. The hardware does not support COMP fields over 9 digits (4 bytes) long. The hardware supports COMP-3 fields up to 31 digits (16 bytes), which is longer than COBOL supports.
One some IBM minicomputers, there is no hardware support for COMP-3, nor do Intel CPUs have COMP-3 support. I don't know whether the latest Intel CPUs support COMP over 9 bytes.
If there is no hardware support, COBOL supports the feature with subroutines, which are relatively quite slow.
One some IBM minicomputers, there is no hardware support for COMP-3, nor do Intel CPUs have COMP-3 support. I don't know whether the latest Intel CPUs support COMP over 9 bytes.
If there is no hardware support, COBOL supports the feature with subroutines, which are relatively quite slow.
My two pennies.....
Having worked on mainframes for the past 20 years, I have come to prefer COMP-3 to COMP. Why? COMP-3 abends rather nicely with an 0C7 if you put rubbish in there, COMP does not. Also, when debugging a COMP-3 field, it is very easy to see what the value is when looking at it in hex. With COMP fields, you have to drag out a calculator and convert the hex value to find out the true value that is being used in a program.
As I said, my 2 pennies, and my preference. Welcome other thoughts......
Having worked on mainframes for the past 20 years, I have come to prefer COMP-3 to COMP. Why? COMP-3 abends rather nicely with an 0C7 if you put rubbish in there, COMP does not. Also, when debugging a COMP-3 field, it is very easy to see what the value is when looking at it in hex. With COMP fields, you have to drag out a calculator and convert the hex value to find out the true value that is being used in a program.
As I said, my 2 pennies, and my preference. Welcome other thoughts......
- Status
Similar threads
- Locked
- Question