enrico, you didn't count the digits in the output
enrico is generally correct. If you define nine digits for a receiving field, and then try to stuff 10 digits into it, you shouldn't be surprised.
When defining a "binary" field in COBOL, the PICture limits the value which can be contained, not the size of the field.
COMP PIC S9(9) is a four-byte binary.
If you consider the binary value that can contain as a maximum, you'll see that all value 0-999,999,999 can be represented, but not all values 0-9,999,999,999. You could have some 10-digit numbers, but not all.
Enterprise COBOL has four binary definitions: BINARY, COMP, COMP-4 and COMP-5. The first three are identical (to the compiler, BINARY and COMP-4 are aliases of COMP). COMP-5 is different, it is "native binary", which means that you can use all the bit-settings available.
You have used a signed field, so you halve the possible positive values. But if you do the calculations your last two results are exaplained.
Ah. But you didn't use COMP-5, you say? Well, you did, because compiler option TRUNC(BIN) has the effect of making all binary definitions into COMP-5.
TRUNC(BIN) is presumably your site default. Which usually means your site is a small one, because there is a performance impact in using TRUNC(BIN) or COMP-5.
However, you can't just change your compiler options which generate code, as the programs will perform differently from before.
If you were to compile with TRUNC(STD) you'd see more normal-looking truncation of your values.
If you were to compile with TRUNC(OPT), you'd be breaking your contract with the compiler. The contract is never put values beyond the range of the PICture with TRUNC(OPT) else you may get unexpected results.