Hi All,
What's the maximum number that can be squeezed into the two different PIC fields above, and how does the TRUNC(BIN/OPT/STD) compiler option affect it.

The reason  I ask is that I am working with a product called HPS which defines it's 'Integer' fields as S9(8) COMP, and then moves it to a DB2 'Integer' field, which is S9(9) COMP. There is a worry that the two are incompatible.

Marc

Marc,

First review Thread209-205700 where I have answered the question of how many decimal digits may be represented by 31 binary digits.  Of course, standard truncation is done on decimal boundaries regardless of the underlying data representation.

My guess is that you will have no problems moving S9(8) to S9(9) under any of the TRUNC options.  If the move were the other direction, there would be differences.  In any event, it would seem that TRUNC BIN would be safest for your problem, assuming it does not cause unwanted side effects.

Tom Morrison

Tom,
I read the thread. And then I read it again. After taking a couple of tablets and having a lie down, I had another go and I'm still not sure I understand!

I know that comp S9(8) and comp S9(9) occupy the same storage (full word) and I'm aware that with the TRUNC(BIN) option of the compiler, truncation should not occur like it would with TRUNC(STD).

I am under the impression that with a comp S9(4) field there is a maximum number that the field can hold, which by your example in the thread, is 32043. Is this the same for comp S9(8/9) and are those values different?

I guess the question that I'm asking is that if I filled the S9(9) comp field with the biggest value that it could take, and moved it to an S9(8) field, would it remain the same value?

Hope this makes sense, and please pardon my ignorance on the math front!

Marc

My understanding of S9(9) COMP and S9(8) COMP is COBOL will manipulate any number up to +/-999,999,999 and +/-99,999,999 respectively.

As to comparing Integers to COBOL PIC 9s:

COBOL PIC 9(4) COMP  max  =  9,999
COBOL PIC 9(5) COMP  max  = 99,999
COBOL NATIVE-2       max  = 65,535
16 bit Integer       max  = 65,535

COBOL PIC 9(8) COMP  max  =    99,999,999
COBOL PIC 9(9) COMP  max  =   999,999,999
COBOL NATIVE-4       max  = 4,294,967,295
32 bit Integer       max  = 4,294,967,295

Dimandja

Correction:

COBOL PIC 9(4) COMP  max  =  9,999
COBOL PIC 9(5) COMP  max  = 99,999
COBOL NATIVE-2       max  = 32,767
16 bit Integer       max  = 32,767

COBOL PIC 9(8) COMP  max  =    99,999,999
COBOL PIC 9(9) COMP  max  =   999,999,999
COBOL NATIVE-4       max  = 2,147,483,647
32 bit Integer       max  = 2,147,483,647

Marc,

I hope that I didn't confuse too much.  To reiterate:

You stated that your issue was moving PIC S9(8) to PIC S9(9).  Under decimal truncation rules, this should not cause any problems.  Likewise, under binary truncation, I don't think there is a problem.

If you have data going the other way, from 9(9) to 9(8), then you definitely have decimal truncation possible.  Binary truncation should not be an issue, though I am not an expert on your particular compiler.

Tom Morrison

Hi,

Try to use COMP-5 instead of COMP.
It will work the same for same storage allocation.
Read your manual about it!
COMP-5 is almost always better than COMP.

Regards,

   Crox

All,
I can't use Comp-5 as on one had I've got a DB2 table and it's dclgen definition, and on the other, the HPS definition, which are not 100% the same. I'm on a manframe and am using an xpediter compile deck which I think is using cobol370, although I'm not positive about this.

There's obviously not a problem going from 9(8) comp to 9(9) and I am beginning to form the impression that the maximum value for the 9(9) comp is the same as 9(8) comp using a  TRUNC(BIN) compile option.

I think that Dimandja has got it right in saying that the max for a half word is 32767 and the max for a full word is 2,147,483,647. I think that both 9(8) and 9(9) comp will hold this max, although I'm open to being persuaded otherwise on this if someone can show me the math. I guess I might have to knock up a program that moves the values to the relevant fields and see what happens. I'm sure I've done this with the 32767 many years ago, and you get an abend. Will try tomorrow and report back, unless someone knows otherwise.......
Marc

Hi Marc,

I've presented the following as fact because it seems clearer without all the ifs maybes and perhapes, but I'm not sure if it's true. I'd like to hear what you all think.
   
I don't know if this point has been addressed, but calculating the capacity of a half word, word, or double word depends on whether or not the field is described as signed or unsigned and the TRUNC option selected at compile time.

As I recall the sign uses the high order bit of the field, reducing the capacity. Assuming TRUNC(BIN), a half word COMP field defined as PIC 9 has the capacity to hold a value up to 65,535 decimal (X'FFFF'); the same field, defined as PIC S9, can hold a value up to 32,767 decimal (X'7FFF').

Regards, Jack.
   

This is from my COBOL85 manual (Tandem/Compaq/HP):

The ranges of values for types NATIVE-2 (16 bits), NATIVE-4 (32 bits), and NATIVE-8 (64 bits) are:

Type                Lower Bound          Upper Bound
NATIVE-2                 -32768               +32767
NATIVE-4            -2147483648          +2147483647
NATIVE-8   -9223372036854775808 +9223372036854775807


The ranges of values for the type COMPUTATIONAL-5 are:

PIC S9(1)- PIC S9(4)  equivalent is NATIVE-2
-32,768 through 32,767 (signed)
or 0 through 65,535 (unsigned)

PIC S9(5)- PIC S9(9)     NATIVE-4     
-2,147,483,648 thru 2,147,483,647 (signed)
or 0 thru 4,294,967,295 (unsigned)

PIC S9(10)- PIC S9(18)   NATIVE-8  
-9,223,372,036,854,775,808  
 thru 9,223,372,036,854,775,807 (signed)
or 0 thru 18,446,744,073,709,551,615 (unsigned)

That should clarify things a bit.

Dimandja

Hi all,
first off many thanks to you all because you've all helped in one way or another, but I feel that Dimandja's posts were the most helpful so I'm going to give D a star. Hope that's ok with the rest of you!

The thing I love about this game is that no matter how long you've been doing it, there's always something new to discover, even if you may have touched on it years ago.

I got the bug on this question when somebody proposed it as a problem on Monday. The system set a value in a Pic S9(8) comp field and moved it to a db2 S9(9) comp field in a table and the table was updated. The scenario I was presented with was that it was causing a problem in production as big values were getting into the table which couldn't subsequently be read using the S9(8) field as key. I was told that TRUNC(BIN) was being used.

My first argument was that if it was ALWAYS sourced from the S9(8) comp field it shouldn't be a problem. I was told that this didn't seem to be the case.

I still had a feeling that this shouldn't have been a problem as I was sure that the number of digits specified in the field size was irrelevant when TRUNC(BIN) as there was a maximum value in half word, word etc. The postings here kind of confirmed my thinking, specifically Dimandja's.

So today, I wrote a program to move various values to various fields. The results kind of surprised me. I moved +32768 to an S9(4) COMP field and looked at the value. It contained -32768. Various higher values moved to the field produced various lower negative numbers.

I reported my findings, namely that S9(8) COMP and S9(9) COMP when used with the TRUNC(BIN) option would contain exactly the same maximum value, only to be told....... 'Oh no, the compile deck is TRUNC(STD)'. - Which does cause a problem!

To summarise all this:
TRUNC(STD) will follow the PIC you define, so S9(4) COMP will allow a maximum of 9999 and a minimum of -9999

TRUNC(BIN) will give:
S9 to S9(4) COMP -32768 to +32767
S9(5) to S9(9) COMP -2147483648 to +2147483647

removing the sign from this option changes the range to:
9 to 9(4) COMP 0 to 65535
9(5) to 9(9) COMP 0 to 4,294,967,295

Once again, thanks for all your help.
Marc