>I feel a little like a Zoroastrian intruding into a discussion among
>Thomist theologians about whether the archangels in moving from
>Samarra to Novara pass through the intervening space, but the whole
>notion of imposing decimal-picture constraints upon binary arithmetic
>strikes me as absurd.
Welcome to absurd-COBOL! The language was designed without regard to
hardware, only with regard to dollars and cents, integers and decimals
in base 10 arithmetic. Mapping decinmal digits to binary data is
and was difficult! How many decimal digits does a fullword hold? :-)
Furthermore, the COBOL Standard requiresthat we support truncation
to the decimal picture string, so if a user codes PIC 9 BINARY, we
must produce a zero result for this math:
COMPUTE PIC9BIN = 9
COMPUTE PIC9BIN = PIC9BIN + 1
>Now that it is available TRUNC(OPT) has everything to recommend it.
>It is faster, more accurate, and yields results that are more
>perspicuous to any but a diseased imagination.
If a user changes a compile option and gets different results, there
will be unhappy clients somewhere. I learned early on that "more
accurate results" means lookout and test a lot before trying!
>Any situation in which the twos-complement byte, halfword, and
>fullword hardware bounds
>
>-128 <=3D y < +127
>(-2^7 <=3D y <=3D +2^7 - 1)
>(-2^15 <- h <=3D +2^15 - 1)
>-32768 <=3D h <=3D +32767
>-2147483648 <=3D f <=3D +2147483647
>(-2^31 <=3D f <=3D +2^31 - 1)
>are adjusted implicitly during and following arithmetic operations
>results in the generation of more (sometimes much more) and sillier
>code. (Explicit operations that use MAX, MIN, or both are available
>for performing such operations where, exceptionally, they are
>appropriate.)
Here is where it gets complicated. We have 3 settings for TRUNC and I think
bone of them will make you happy :-)
TRUNC(STD) : Generate extra code to make sure results a truncated to PICTURE
clause
TRUNC(OPT) : Generate the minimum amount of code without regard to PICTURE
clause
TRUNC(BIN) : Generate extra code to use all bits of BINARY data even though
binary r
data does not map to decimal PICTURE clauses.
COBOL V5 gets the same results as earlier compilers, and there is no such thing
as
a super efficient data type and compiler option combination that will fully
exploit
binary data on z/OS. For performance we recommend TRUNC(OPT), but in some
cases
data can be lost, so not all users can use TRUNC(OPT). Usually customer
dicsussions
are between TRUNC(OPT) and TRUNC(BIN), TRUNC(STD) is rarely used.
Cheers,
TomR >> COBOL is the Language of the Future! <<
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
