IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

how to store a billion number in a 8 bytes field


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
bigboy0723

New User


Joined: 16 Jul 2005
Posts: 3

PostPosted: Thu Aug 30, 2012 9:52 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Aug 30, 2012 9:59 pm
Reply with quote

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
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Thu Aug 30, 2012 10:10 pm
Reply with quote

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
View user's profile Send private message
Craq Giegerich

Senior Member


Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA

PostPosted: Thu Aug 30, 2012 10:52 pm
Reply with quote

What about s9(13)v99 comp-3 or s9(15) comp-3 those are still 8 bytes.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Aug 30, 2012 11:04 pm
Reply with quote

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. icon_wink.gif

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
View user's profile Send private message
bigboy0723

New User


Joined: 16 Jul 2005
Posts: 3

PostPosted: Thu Aug 30, 2012 11:47 pm
Reply with quote

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
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Fri Aug 31, 2012 12:05 am
Reply with quote

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:
  1. He introduced a radix point into a binary field (which is one of the stupider things that can be done)
  2. 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))
  3. 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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Aug 31, 2012 12:12 am
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Fri Aug 31, 2012 6:25 am
Reply with quote

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
View user's profile Send private message
bigboy0723

New User


Joined: 16 Jul 2005
Posts: 3

PostPosted: Fri Aug 31, 2012 9:06 am
Reply with quote

Thanks everyone for their time and advise. I think I have better understanding now and have enough information to move on.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Pulling a fixed number of records fro... DB2 2
No new posts Substring number between 2 characters... DFSORT/ICETOOL 2
No new posts Replace Multiple Field values to Othe... DFSORT/ICETOOL 12
No new posts Generate random number from range of ... COBOL Programming 3
No new posts Increase the number of columns in the... IBM Tools 3
Search our Forums:

Back to Top