|
View previous topic :: View next topic
|
| Author |
Message |
sivasaras
New User
Joined: 29 Sep 2007
Posts: 93
Location: chenna/i-
|
|
|
|
Hi,
What is the maximum value comp, comp-1, comp-2, comp-3 can store?
Regards,
Siva |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
At the top of the page is a link to "IBM Manuals". At the top are manuals for several current releases of cobol.
Look in the language reference for the version you are using. If you find something in the docmentation that is not clear, post what you found and your doubt about it. Someone will be able to clarify.
Start with "Numeric Items". |
|
| Back to top |
|
|
jctgf
Currently Banned
Active User
Joined: 04 Nov 2006
Posts: 109
|
|
|
|
Hi,
I'll try to answer your question partially.
Comp is a binary field in Cobol.
Comp fields may have 2 or 4 bytes. In a two byte field, you can store 2**7 or 32768.
However, one bit is reserved for the sign. So you should be able to store a value up to 32767 in it.
Once in Cobol you always express the number of digits of a field, you would have to declare pic s9(05) comp to move 32767 to it. By doing so, Cobol would leave a door open for someone mistakenly move the value 55123, for example, to this variable. This value fits in a 9(05) picture but it would be a mistake because this field can only store up to 32767.
To avoid this kind of mistake, the picture representation for a 2-byte binary field in Cobol is always pic s9(04) comp. It limits the maximum value in a 2-byte field to 9999 and it's a waste. If you want to use the full capacity of a 2-byte binary field, you should use comp-5 instead of comp. Just declare pic s9(04) comp-5. It will allow you to store a value up to 32767. I don't remember what happens if you try to move a value bigger than that to this kind of variable. Probably there will be some sort of numeric truncation.
All I said about a 2-byte binary variable applies to a 4-byte binary one. The only difference is that the upper limit of this variable is 2**15.
Comp-3 is used for zoned decimal variables. You can store any value up to 18 digits (plus a sign) in it.
One last thing: there is a compiler option is Cobol that extends these limits a lot. Comp-3 variables will store values with up to 31 digits. I don't remember the maximum value for binary variables when you use this compiler option.
I also don't remember the name of the compiler option (I think it is “arith”) but you can easily find it in any IBM Cobol Manual. This compiler option, though, may affect the program performance, according to the manual.
As to comp-1 and comp-2, I rarely used it and so won't make any comment about.
Good luck. |
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
jctgf,
Please try to encourage looking things up in the manual as Dick did. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
jctgf, you have so many errors, misunderstandings, and problems with what you posted that you may want to retract it.
1. 2**7 is 128, not 32768.
2. A 2-byte binary field actually handles 65536 (2**16) values -- from negative 32768 to 32767. You cannot actually store +32768 in a 2-byte binary variable.
3. COBOL uses the TRUNC compiler option to determine what happens when you move a value larger than the PIC size to a variable; it may allow the value or force truncation to the picture size.
4. The manual is easily accessible from the Manuals link at the top of the page so you can tell exactly what happens in COBOL for pretty much everything you attempt.
5. Comp fields may have 2 or 4 bytes as you state, but they can also have 8 bytes (PIC S9(18) is the largest COMP picture allowed per the manual).
6. A full word (4-byte) COMP variable handles 2**32 values (over 4 billion values, not 2**15 which is 32768).
7. COMP-3 is used to store packed decimal values, not zoned decimal.
8. COMP-3 and zoned decimal variables can, using the ARITH(EXTEND) compiler option, hold up to 31 digits -- not 18 as you state. This option may be set permanently at a site so you cannot simply state that 18 is the limit always as that is not true.
9. The number of digits for binary variables does not change when using ARITH(EXTEND) -- a double word (8 bytes) is as large as they can get, period.
10. A double word COMP variable handles 2**64 values, so the range is negative 2**63 to positive 2**63-1.
11. PIC S9(09) is the limit for 4-byte binary variable pictures -- anything larger forces a double word.
12. Declaring a binary variable as PIC S99999 forces it to be a full word (4 bytes) so much of what you said about this picture size does not apply.
13. COMP-1 variables are full word floating point values where 1 bit is used for the sign, 7 bits for the exponent (excess 64 so a COMP-1 variable that starts with hex 43 is a positive value raised to the third power), and 24 bits for the actual value.
14. COMP-2 variables use 1 sign bit, 7 exponent bits and 56 bits for the value.
15. You said "Once in Cobol you always express the number of digits of a field". This is certainly not true for COMP-1 and COMP-2 fields, nor is it true for POINTER variables. |
|
| Back to top |
|
|
jctgf
Currently Banned
Active User
Joined: 04 Nov 2006
Posts: 109
|
|
|
|
Hi,
Thank you for correcting my mistakes.
I replied quickly and missed some numbers and points. It was almost midnight when I wrote the post. I was tired and in a rush. No excuse, though.
When I said zoned variables, I meant packed. Some times I get lost in translations. English is not my 1st language.
In some cases, I didn't want to get into too much details.
Comp-3 can hold up to 18 digits or 31, with the proper compiler option (arith). I said that. ' ' It can also be set during execution time. I didn't say that.
As to comp-1 and comp-2 I mentioned I wasn't familiar with that. ''
As to item 12, you didn't understand my point. What I meant is that - despite having the capacity to store 32687 in 2-bytes - you can't do that with comp. You have to use comp-5.
As to the 32678 value in a 2-byte binary, I tried to explain that the real range is limited to 32687 because there's a signal (sign?).
As to the negative values, I preferred not to get into these details.
I regret I wrongly calculated the maximum possible value for the binary fields. I don't have those number in my mind. I need to calculate them whenever I need. Silly mistake.
Generally speaking, I should have been more careful. I agree with you.
Unfortunately I can't edit and correct my reply. The site doesn't allow.
Thank you. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| As to item 12, you didn't understand my point. What I meant is that - despite having the capacity to store 32687 in 2-bytes - you can't do that with comp. You have to use comp-5. |
You are, again, wrong. If TRUNC(BIN) is used as the compile option, COBOL allows a binary field to hold all possible values -- it does not limit the values to the size of the picture clause. So 32767 can be stored in a 2-byte binary field when TRUNC(BIN) is the compile option. COMP-5 is merely a form of COMP that treats the variable as if TRUNC(BIN) is set.
When you post a reply, it is your responsibility to verify that everything you say is accurate. I use the manuals heavily when writing responses as I don't want to put out incorrect information. A response such as yours has two negative consequences: (1) somebody may rely upon wrong information and thereby have problems, and (2) by not checking your basic facts (calculator is available on every PC and makes checking 2**7, for example, very easy), you do not impress anyone with your competence. |
|
| Back to top |
|
|
jctgf
Currently Banned
Active User
Joined: 04 Nov 2006
Posts: 109
|
|
|
|
yes, you're right. my fault.  |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Adding to this, COMP-5 was introduced with OS/390 COBOL 2.2.1 and is known as "Native Binary".
The "TRUNC" option has no effect on COMP-5 variables.
Similar to the "TRUNC(BIN)" option, COMP-5 variable values are never truncated based upon their PICTURE clause number of digits.
Internally to ensure this, the compiler uses ICM and STCM instructions on COMP-5 non-float variables to avoid truncation.
Bill |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
| Quote: |
| As to the 32678 value in a 2-byte binary, I tried to explain that the real range is limited to 32687 because there's a signal (sign?). |
Negative values in binary fields are expressed in two's complement where the high order bit is always set for negative numbers.
A -1 is in a signed 2 byte binary is thus x'FFFF' (all bits set) and -32678 is represented as x'8000' (only the high order bit set).
The highest positive value that can be represented is +32767, represented as x'7FFF' (all bits set except the high order bit).
If you treat the field as unsigned, x'FFFF' will be interpreted as decimal 65535.
You can look up two's complement in Wikipedia, which also has a very mathematical definition of the term. |
|
| Back to top |
|
|
deepak_shrivastava
New User
Joined: 05 Jan 2016
Posts: 8
Location: India
|
|
|
|
| Robert Sample wrote: |
jctgf, you have so many errors, misunderstandings, and problems with what you posted that you may want to retract it.
1. 2**7 is 128, not 32768.
2. A 2-byte binary field actually handles 65536 (2**16) values -- from negative 32768 to 32767. You cannot actually store +32768 in a 2-byte binary variable.
3. COBOL uses the TRUNC compiler option to determine what happens when you move a value larger than the PIC size to a variable; it may allow the value or force truncation to the picture size.
4. The manual is easily accessible from the Manuals link at the top of the page so you can tell exactly what happens in COBOL for pretty much everything you attempt.
5. Comp fields may have 2 or 4 bytes as you state, but they can also have 8 bytes (PIC S9(18) is the largest COMP picture allowed per the manual).
6. A full word (4-byte) COMP variable handles 2**32 values (over 4 billion values, not 2**15 which is 32768).
7. COMP-3 is used to store packed decimal values, not zoned decimal.
8. COMP-3 and zoned decimal variables can, using the ARITH(EXTEND) compiler option, hold up to 31 digits -- not 18 as you state. This option may be set permanently at a site so you cannot simply state that 18 is the limit always as that is not true.
9. The number of digits for binary variables does not change when using ARITH(EXTEND) -- a double word (8 bytes) is as large as they can get, period.
10. A double word COMP variable handles 2**64 values, so the range is negative 2**63 to positive 2**63-1.
11. PIC S9(09) is the limit for 4-byte binary variable pictures -- anything larger forces a double word.
12. Declaring a binary variable as PIC S99999 forces it to be a full word (4 bytes) so much of what you said about this picture size does not apply.
13. COMP-1 variables are full word floating point values where 1 bit is used for the sign, 7 bits for the exponent (excess 64 so a COMP-1 variable that starts with hex 43 is a positive value raised to the third power), and 24 bits for the actual value.
14. COMP-2 variables use 1 sign bit, 7 exponent bits and 56 bits for the value.
15. You said "Once in Cobol you always express the number of digits of a field". This is certainly not true for COMP-1 and COMP-2 fields, nor is it true for POINTER variables. |
Thank You !!
If possible, Can you please tell the exact range of -VE to +VE value S9(4) COMP-3 can hold.
And How will they be store in this storage of 3 byte |__|__|__|.
I will be really thank full for this. |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
You can have values in the range -9999 to +9999 in a S9(4) COMP-3 (packed decimal) field.
Corresponding hexadecimal notations in 3 bytes are: x'09999D' to x'09999C'. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Deepak, the information you asked for is easily found in the Enterprise COBOL Programming Guide -- look for a chapter titled Formats for Numeric Data. Or look at the Compiler Limits appendix of the Language Reference manual. |
|
| Back to top |
|
|
deepak_shrivastava
New User
Joined: 05 Jan 2016
Posts: 8
Location: India
|
|
|
|
| Kjeld wrote: |
You can have values in the range -9999 to +9999 in a S9(4) COMP-3 (packed decimal) field.
Corresponding hexadecimal notations in 3 bytes are: x'09999D' to x'09999C'. |
Hi, Thank You !!
Just one doubt ,
will it be stored like |09|99|9D| in 3 byte
or |99|99|D | (after D half slack byte) in 3 byte . |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
A packed decimal (COMP-3) variable ALWAYS has an odd number of digits. If you define it as PIC S9(4) COMP-3, it will have 5 digits (2 per byte for the first 2 bytes, 1 digit and the sign field in the last byte) and as Kjeld showed the first digit will ALWAYS be zero.
And your post makes no sense, by the way. Every bit of every byte in the computer ALWAYS has a value -- zero or one for the bits. So having a blank half-byte just won't happen, ever. |
|
| Back to top |
|
|
Auryn
New User
Joined: 11 Jan 2006
Posts: 83
Location: Lower Saxony (DE)
|
|
|
|
Hello everybody
lots of answers here about TRUNC(BIN) respectively STD and OPT.
And of cause read the f*** manual.
But imo the manuals examples don’t answer the most important part of the question, the question for the „grey zone“, the range of 10000 to 32767 respectively -10000 to -32768.
The manual talks about S9(2) and 9(6) BINARY which is in my opinion and in my experience pretty unusual. (Think, S9(4) or S9(8) are way more usual BINARY formats.) And the given sample values are not part of that „grey zone“.
So can anybody give us a detailed comparison of the behaviour in effect oft he TRUNC options BIN, STD and OPT of values like
» 12345 (in the range of 10000 to 32767)
» 34567 (outside that range)
and maybe - for the sake of completeness – their negative values as well.
Thank you very much |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2022
Location: USA
|
|
|
|
| Auryn wrote: |
Hello everybody
lots of answers here about TRUNC(BIN) respectively STD and OPT.
And of cause read the f*** manual.
But imo the manuals examples don’t answer the most important part of the question, the question for the „grey zone“, the range of 10000 to 32767 respectively -10000 to -32768.
The manual talks about S9(2) and 9(6) BINARY which is in my opinion and in my experience pretty unusual. (Think, S9(4) or S9(8) are way more usual BINARY formats.) And the given sample values are not part of that „grey zone“.
So can anybody give us a detailed comparison of the behaviour in effect oft he TRUNC options BIN, STD and OPT of values like
» 12345 (in the range of 10000 to 32767)
» 34567 (outside that range)
and maybe - for the sake of completeness – their negative values as well.
Thank you very much |
Extremely clear explanation, with detailed examples, in plain English:
Enterprise COBOL for z/OS. TRUNC options |
|
| Back to top |
|
|
|
|
