Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

how to store a billion number in a 8 bytes field

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
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    Post subject: how to store a billion number in a 8 bytes field
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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Thu Aug 30, 2012 9:59 pm    Post subject: Reply to: how to store a billion number in a 8 bytes field
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: 1738
Location: Bloomington, IL

PostPosted: Thu Aug 30, 2012 10:10 pm    Post subject: Re: how to store a billion number in a 8 bytes field
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    Post subject:
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: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Aug 30, 2012 11:04 pm    Post subject: Reply to: how to store a billion number in a 8 bytes field
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    Post subject:
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: 1738
Location: Bloomington, IL

PostPosted: Fri Aug 31, 2012 12:05 am    Post subject:
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: 7913
Location: Bellevue, IA

PostPosted: Fri Aug 31, 2012 12:12 am    Post subject:
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

Site Director


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

PostPosted: Fri Aug 31, 2012 6:25 am    Post subject:
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    Post subject:
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    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Performing arithmetic on input field zh_lad DFSORT/ICETOOL 17 Tue Dec 06, 2016 8:04 pm
No new posts Add PD field from 2nd file to PD in 1st Sushant Garje DFSORT/ICETOOL 6 Thu Dec 01, 2016 4:32 pm
No new posts How to split the records using the am... vnktrrd DFSORT/ICETOOL 24 Fri Oct 28, 2016 7:33 pm
No new posts Sort records based on numeric field. Alks SYNCSORT 2 Wed Oct 19, 2016 10:14 pm
No new posts Amount field is getting corrupted whe... thesumitk SYNCSORT 5 Tue Oct 18, 2016 8:20 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us