View previous topic :: View next topic
|
Author |
Message |
bigboy0723
New User
Joined: 16 Jul 2005 Posts: 3
|
|
|
|
Hi All.
I have a question and hoping that someone could help me.
I have a copybook which a few premium fileds that are defined as PIC S9(06)V9(02) COMP.
When I look at the record in hex.
0716320{
FFFFFFFC
07163200
will display as 71632.00.
The problem that I have is how to store billion numbers into this filed without expanding the field size. With the current design, the max that I could have is 999999.99. I could take away the 2 digits after the decimal points to make it 99999999 but it still less than a billion..
I am also thinking of expanding the field to allow a billion dollar number; which means I have to re-format a lot of existing records, they could be dated back to 1970s. I a trying to avoid doing this.
Alternatively, I am thinking of storing the number into a hex format. So, 71632 becomes x'117D0'. So, with the current 8-bytes field, theoretically, I could store up to x'FFFFFFFFFFFFFFFF'. which is a 18446744073709551615 in decimal. Not sure if that is possible. Also, can I store a -ve number in this hex format?
William |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
A double-word binary is eight bytes, which you just happen to have.
Yes, you can store a negative value. It halves the maximum value you can have, but that would still be OK.
Have you considered COMP-1 or COMP-2?
Have you got a lot of fields you need to do this to? Have you got a lot of records? |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
I am confused. You say:
bigboy0723 wrote: |
I have a copybook which a few premium fileds that are defined as PIC S9(06)V9(02) COMP. |
which is binary (perhaps constrained by the PICTURE), but you also say:
Quote: |
When I look at the record in hex.
Code: |
0716320{
FFFFFFFC
07163200 |
will display as 71632.00. [/code] |
which is not binary, but overpunched (i.e., signed) zoned decimal; the COBOL USAGE clause, IIRC, would be DISPLAY. Which is it? |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
What about s9(13)v99 comp-3 or s9(15) comp-3 those are still 8 bytes. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
With the correct compiler option (TRUNC(BIN)) for non-COMP-5 or just plain COMP-5 (Native Binary, TRUNC option has no effect), you can store up to X'7FFFFFFF' (2,147,483,647) in a signed fullword (4-Bytes).
Are you expecting significant growth? I don't think Turkish Lira is used anymore.
But, if the field is already 8-Bytes, you could look into redefining it as S9(13)V99 PACKED-DECIMAL. It's a much more friendly definition and you can store far greater than one billion with ease. |
|
Back to top |
|
|
bigboy0723
New User
Joined: 16 Jul 2005 Posts: 3
|
|
|
|
I hope I didn't confuse anymore here.
The field is defined as 05 ORIGINAL-PREM PIC S9(06)V9(02) COMP.
And when mentioned that I looked at the record in hex. I actually meant that I have the hex option turned on when I view the record in utility INSYNC.
If I go with the route to expand the original filed size to PIC S9(010)V9(02) COMP. I could be looking at re-formatting years of data, both on-site and off site.
With all the suggested ideas, I think comp-3 might be a possible solution. I will redefine the current PIC S9(06)V9(02) COMP filed to S9(13)v99 comp-3. In addition, I will also add a new hex-indicator filed inside the record to determine which field definition to use. By doing this, I hope I don't have to modify the old records.
So, with this S9(13)v99 comp-3 definition in a 8-bytes field. What is the range of numbers that I can store? Is it from 9223372036854775807 to -9223372036854775807?
I don't expect there will be a lot of cases that the number will go beyond 10 billions, this is for the insurance limit, it could be for a shopping plaza or a building complex. But you never know.
Thanks,
William |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
bigboy0723 wrote: |
I hope I didn't confuse anymore here. |
I think that the confusion may be on your part.
Quote: |
The field is defined as 05 ORIGINAL-PREM PIC S9(06)V9(02) COMP.
And when mentioned that I looked at the record in hex. I actually meant that I have the hex option turned on when I view the record in utility INSYNC. |
But you showed zoned decimal data, not a simple binary number.
I think that what may have happened is something like this: a long time ago (albeit not in a galaxy far away) ORIGINAL-PREM was defined as S9(06)V9(02) DISPLAY. At some point, a predecessor was faced with the same problem that you have now, viz., trying to put a value in excess of 999,999.99 in that field. Rather witlessly, he just changed the USAGE of DISPLAY to COMP (or perhaps just added usage of COMP; DISPLAY has always been the default and is rarely specified. Unfortunately:
- He introduced a radix point into a binary field (which is one of the stupider things that can be done)
- He may not have realized that the maximum value was still constrained by the picture (unless, as Mr. O'Boyle says, programs using that copybook are compiled with TRUNC(BIN))
- He didn't convert existing data and/or didn't recompile all programs using this copybook; the data that you show is overpunched zoned decimal.
Quote: |
With all the suggested ideas, I think comp-3 might be a possible solution. I will redefine the current PIC S9(06)V9(02) COMP filed to S9(13)v99 comp-3. In addition, I will also add a new hex-indicator filed inside the record to determine which field definition to use. By doing this, I hope I don't have to modify the old records.
So, with this S9(13)v99 comp-3 definition in a 8-bytes field. What is the range of numbers that I can store? Is it from 9223372036854775807 to -9223372036854775807? |
It's -9,999,999,999,999.99 to 9,999,999,999,999.99; COMP-3 is packed decimal.
Without meaning insult, may I inquire as to your COBOL experience? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
So, with the current 8-bytes field |
I want to be sure you CLEARLY understand something: PIC S9(06)V9(02) COMP is stored by COBOL as a FOUR byte variable, NOT an eight-byte variable. The variable uses 8 bytes as DISPLAY but only 4 bytes as COMP. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
I believe this dialog indicates that you need to spend considerable time learning the different PICTUREs for numeric data, how much space each allocates, what your data actually is and how thiese fields are defined in the code that creates it (writes it into the file you are reading).
All of the info about PICTUREs and bytes allocated is covered very well in the COBOL Language Reference available via the "IBM Manuals" link at the top of the page. If you find sometnhing in the manual that is not clear, post what you found and your doubt. Someone will be able to clarify. |
|
Back to top |
|
|
bigboy0723
New User
Joined: 16 Jul 2005 Posts: 3
|
|
|
|
Thanks everyone for their time and advise. I think I have better understanding now and have enough information to move on. |
|
Back to top |
|
|
|