Integer limit 32767 problem 1

[raccess]

Hi,

I have one COBOL module which adds data in to db2 table field which has integer data type. If value exceeds limit of 32767 then it converts it into negative number. I need any formula which I can apply on to this negative no to convert it in to its appropriate positive no.

Any idea any thought how I can do it or any other solution to solve this problem?

Thanks,

Raccess

 

[hnkadmn]

Hi

We are able to store upto 999,999. didn't faced any problems. May I have your insert statement.

try integer(col) in insert statement.

Hari

 

[hnkadmn]

Hi

Is the data type is SMALLINT or INTEGER.
The smallint allows only upto 32767. check the table definition.

Hari

 

[raccess]

I'm able to fix it. Any way thanks for your reply. Solution is add 65536 in to negative no & it will bring up actul positive no.

-Raccess

 

[MarcLodge]

The 'problem' is to do with the way in which Cobol handles Comp fields, whether they are signed or not, and what compile options you have specified.

The compile option TRUNC(STD) will follow the PIC you define, so S9(4) COMP will allow a maximum of 9999 and a minimum of -9999

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

If you were to remove 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

Hope this helps.

Marc

 

[Crox]

Hi,

COMP-5 is not sensitive for TRUNC.

Regards,

Crox

 

[MarcLodge]

When creating cobol DCLGEN members using the IBM generator, Integer fields get defined as S9(9) COMP and Small Int as S9(4) COMP. Not a hint of a COMP-5 field in sight.

 

[Crox]

When your compiler options are not ok, you can have a problem. Also the performance will be less. You can change the COMP into COMP-5 if you want. IBM should do that too.

 

[marjam]

Rather then trying to make a small interger hold more then its meant to you should have the table changed to make it a large interger or a decimal.

You are playing with fire when you alter the true function of a field. This will be undocumented and may cause confusion for the people maintaining this table.

IT DB2 DBA

 

[Crox]

It is documented. Look at the manuals. It is high speed. It saves a lot of money without trouble.

 

[MarcLodge]

There appears to be some confusion in this thread. The original request stated that a value greater than 32767 could not fit into an integer field, which is not the case as it can. We must therefore assume that the field is a small integer. If this is the case, and we have the situation where a small integer field is expected to hold a value greater than 32767, then clearly that field has been incorrectly specified, and should be changed.

Crox, are you suggesting that the S9(4) COMP field should be have it's generated DCLGEN definition overwritten to a COMP-5, and that this will solve the problem? If so, I think this would be an appalling thing to do. It would almost guarantee live problems in the future if the DCLGEN ever changed and the field was not again overwritten with COMP-5. I can only assume that I have misunderstood you.

Marc