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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
What is the largest numeric value stored in pic s(5)v999
- Thread starter gotmilk2
- Start date
I assume you meant S9(5)V99 as I believe S(5)V99 is illegal.
What will be stored is 9999900 assuming that the underlying USAGE phrase allows a number of that magnitude (e.g. S9(5) COMP on an IBM mainframe may not be able to store numbers larger than +32767 depending on the compiler options). (I'm also assuming you're not dealing with floating point USAGE.)
How the sign is handled depends on the USAGE and/or SIGN clauses.
Regards,
Glenn
What will be stored is 9999900 assuming that the underlying USAGE phrase allows a number of that magnitude (e.g. S9(5) COMP on an IBM mainframe may not be able to store numbers larger than +32767 depending on the compiler options). (I'm also assuming you're not dealing with floating point USAGE.)
How the sign is handled depends on the USAGE and/or SIGN clauses.
Regards,
Glenn
Anything larger than 99999.99 will be turncated.
Anything smaller than -99999.99 will be truncated.
It will round to match the Precision. If you enter something like 2345.567 then you will get 2345.57.
It is up to the programmer to control the limits of what can go into the storage you have reserved.
You should probably store at least one more precision than you want to retrieve. Some people want like 5 decimal points for rounding in accounting applications. Would look like 2345.00001. If you are doing division then the precision of the number is important when and if you have to start rounding.
Rounding errors can creep in if you are not careful.
If you do not like my post feel free to point out your opinion or my errors.
Anything smaller than -99999.99 will be truncated.
It will round to match the Precision. If you enter something like 2345.567 then you will get 2345.57.
It is up to the programmer to control the limits of what can go into the storage you have reserved.
You should probably store at least one more precision than you want to retrieve. Some people want like 5 decimal points for rounding in accounting applications. Would look like 2345.00001. If you are doing division then the precision of the number is important when and if you have to start rounding.
Rounding errors can creep in if you are not careful.
If you do not like my post feel free to point out your opinion or my errors.
ceg4702 said:
No, 'it' will not. The OP states 'move to'. Only arithmetic statements have the possibility of rounding, and then round only if the ROUNDED clause is specified.
Of course, the OP is also...gone!
Tom Morrison
George1111
Programmer
NORMAL RULES
This is normally the case (as explained above)
Anything larger than 99999.99 will be truncated.
Anything smaller than -99999.99 will be truncated.
HOWEVER
If the value is stored as a computational variable, then internally, the variable is stored "Base 16" - ie, each semi-byte of the variable has a value from hex 0 to hex F
This then would mean that a PIC 9(2) COMP can actually store from 00 up to FF (0 - 255)
This is great until you try to print the variable when you would normally encounter a run time error as the variable, while defined as 2 digits, now has 3 digits - CRASH !
Follow normal rules and you shouldn't have problems
This is normally the case (as explained above)
Anything larger than 99999.99 will be truncated.
Anything smaller than -99999.99 will be truncated.
HOWEVER
If the value is stored as a computational variable, then internally, the variable is stored "Base 16" - ie, each semi-byte of the variable has a value from hex 0 to hex F
This then would mean that a PIC 9(2) COMP can actually store from 00 up to FF (0 - 255)
This is great until you try to print the variable when you would normally encounter a run time error as the variable, while defined as 2 digits, now has 3 digits - CRASH !
Follow normal rules and you shouldn't have problems
No, COMP fields are stored Base 2. That is what binary meams. You are perhaps confused with "floating point" fields, in which the exponents are powers of 16 (on most PC hardware). And if a PIC 9(2) COMP field were to contain a value higher than 99 or lower than -99, it is not likely to cause a "CRASH" in any system I have worked on, which number in the dozens. And since you cannot generally "print" any COMP field, that statement is meaningless.
Actually, if one were to read the standard, one would soon find out that COMP doesn't imply anything about the storage mechanism.
Tom Morrison
2002 standard said:
Tom Morrison
George1111
Programmer
I use BOS Cobol
If you examine a record on DISK with a HEX VIEWER then you will see data stored in HEX with values of Semi-Bytes being between 0 and F
ie, a Value of 12 in a Pic 9(2) Comp field (which takes up 1 byte) would look like '0C'
How would the same value look like in your cobol (when viewed with a HEX Viewer) ?
(BOS Cobol allows you to print Comp fields)
If you examine a record on DISK with a HEX VIEWER then you will see data stored in HEX with values of Semi-Bytes being between 0 and F
ie, a Value of 12 in a Pic 9(2) Comp field (which takes up 1 byte) would look like '0C'
How would the same value look like in your cobol (when viewed with a HEX Viewer) ?
(BOS Cobol allows you to print Comp fields)
Ok George, what do you mean by "print"? The only COBOL reference to "print" that I have ever seen is that a file can be assigned to "PRINTER" or "PRINTER-1".
Do you mean that a record in a file that is intended to be sent to a printer can contain a computational field? In this case, any compiler will allow you to "print" computaional fiels, as they do no do such a high-level checking as to test whether you are sending a computational field to a printer. The only analogous checking I have seen is the standard restriction on DISPLAYing a comutational field, which is relaxed in many compilers. In this case, the field is internally converted to DISPLAY before being sent to the display device.
Do you mean that a record in a file that is intended to be sent to a printer can contain a computational field? In this case, any compiler will allow you to "print" computaional fiels, as they do no do such a high-level checking as to test whether you are sending a computational field to a printer. The only analogous checking I have seen is the standard restriction on DISPLAYing a comutational field, which is relaxed in many compilers. In this case, the field is internally converted to DISPLAY before being sent to the display device.
It may be in the thread somewhere, but if you are using a compiler that reats COMP the same as USAGE BINARY (which many do - but not all) *AND* you are running in "standard conforming mode" then it is true that a field like:
05 Num1 Pic S9(5)V99 COMP.
will "truncate" above +99999.99 or below -99999.99.
However, many (most?) compilers also have a way of running in NON-conforming mode where such fields will be allowed to "store" as large as can fit in (when stored in base 2).
As far as "base 2" vs "hex", it is true that on 8-bit machines, base 2 values are often refered to via their hex values, but are (almost?) always stored in binary. After all, most computers only understand "0" and "1".
Bill Klein
05 Num1 Pic S9(5)V99 COMP.
will "truncate" above +99999.99 or below -99999.99.
However, many (most?) compilers also have a way of running in NON-conforming mode where such fields will be allowed to "store" as large as can fit in (when stored in base 2).
As far as "base 2" vs "hex", it is true that on 8-bit machines, base 2 values are often refered to via their hex values, but are (almost?) always stored in binary. After all, most computers only understand "0" and "1".
Bill Klein
George1111
Programmer
Sorry guys - I am saying "PRINT" but am meaning Display on the Screen
(Spent too much time in VB Land where Print is used to Display data)
So if the Pic 9(2) Comp field contains 123 (it has a maximum value of hex FF = 256), then I would normally get a crash - its trying to print 3 digits when the compiler expected a maximum of 2
My basic point was - does your cobol allow the storage of "packed" data so that you can get a similar result to my cobol.
If a field is Pic 9(6) comp it takes up 3 bytes in my system
6 digits traditionally means 999999 as a maximum capacity.
However, 3 bytes in my language can store (in packed format) FFFFFF which is 16777215 !
(Spent too much time in VB Land where Print is used to Display data)
So if the Pic 9(2) Comp field contains 123 (it has a maximum value of hex FF = 256), then I would normally get a crash - its trying to print 3 digits when the compiler expected a maximum of 2
My basic point was - does your cobol allow the storage of "packed" data so that you can get a similar result to my cobol.
If a field is Pic 9(6) comp it takes up 3 bytes in my system
6 digits traditionally means 999999 as a maximum capacity.
However, 3 bytes in my language can store (in packed format) FFFFFF which is 16777215 !
To determin if your compiler supports larger than the base-10 values specified by the number of "9's" in the PICTURE in COMP-? or USAGE BINARY fields, check for a compiler option (or directive) similar to:
TRUNC/NOTRUNC
or
TRUNC(STD)
When running in "standard" (TRUNC) mode, then truncation is based on base-10 (even for items stored in binary). When running in "non-conforming" mode, you PROBABLY can store values up to X"FF".
For an interesting example of the implications of this (in one COBOL implementation) look at:
and
***
However, be aware that these results are NOT the same in all implementations that allow storing X"FFFF" in a two-byte binary field.
Bill Klein
TRUNC/NOTRUNC
or
TRUNC(STD)
When running in "standard" (TRUNC) mode, then truncation is based on base-10 (even for items stored in binary). When running in "non-conforming" mode, you PROBABLY can store values up to X"FF".
For an interesting example of the implications of this (in one COBOL implementation) look at:
and
***
However, be aware that these results are NOT the same in all implementations that allow storing X"FFFF" in a two-byte binary field.
Bill Klein
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Helpful tip