Re: Max integer in an 8 byte COMP field?

A couple of comments:

1) how "COMP" data is stored is totally up to the implementor. It can be
"binary" "display-base-10" "packed-decimal" or anything else. It is TRUE that
VisualAge COBOL (a product no longer supported by IBM) did use binary.

2) In many implementations there is some compiler option or directive that talks
about whether a COMP (or BINARY) field can hold the "maximum" allowed by the
space allocation - vs the largest specified by the PICTURE clause. In most
cases this is something with "TRUNC" in it. WHICH operations this impacts is
also up to the implementor. The only thing that the Standard says is that when
you try and use values greater than the number of digits specified in the
PICTURE - "results are unpredictable" (unless you use the ON SIZE ERROR for
certain operations, like COMPUTE).

3) The '85 Standard allowed a maximum of 18 digits; the '02 Standard allows 31.

4) Until you get to the '02 Standard (and IBM definitely is NOT an 02 compliant
compiler) results of ALL compute statements use "native arithmetic" and results
are implementor defined. IBM is famous for certain times where COMPUTE
statements using certain fields definitions for

*7 / 4) * 4 (using fields with no decimal points

yields a result of 4, not 7 .... and this is FULLY "ANSI conforming" behavior

The '02 Standard introduces "ARITHMETIC IS STANDARD" but I don't know of any
conforming implementations of that. And even that NEVER guarantees results for
most exponentiation.

****

Bottom-Line:
As asked, this question has no meaning. If you want to know how large a
value a specific compiler will allow in a specific field type for a specific
statement with specific compiler options, then testing it is probably the best
way to get an answer. Otherwise, NEVER use a numeric value greater than the
PICTURE clause allows. Also you should always use an ON SIZE ERROR phrase for
arithmetic statements that might have very large numbers.

--
Bill Klein
wmklein <at> ix.netcom.com
"Graham Hobbs" <ghobbs@xxxxxxxxxxx> wrote in message
news:j9nh23lfuelrdtvktcjh84ugd6s9kjh51u@xxxxxxxxxx
Hello,

I can't figure this out.
Am trying to find the largest integer that will fit inside a 'comp'
field of 8 bytes (64 bits).
Below is the compiler output followed by execution results.
I tried with both signed and unsigned COMP fields.

I can understand why exponents of 64 and 65 go to zero (I think) but:

1. why at 62 does the displayed result have 19 digits (when my Cobol
manuals tell me 18 is the maximum).
2. same for 63, but additionally, why has it gone negative.
3. I still don't know what the largest integer can be.

Any ideas please, thanks.

Graham Hobbs

..............................................

Compiler (VisualAge Cobol V2.2) output:

000091 05 RES1 PIC 9(18) COMP. 8(0000221)
000092 05 RES2 PIC S9(18) COMP. 8(0000229)


000115 DISPLAY '--------------------------------'
000116 COMPUTE RES1 = 2 ** 62 DISPLAY ' RES1=' RES1
000117 COMPUTE RES1 = 2 ** 63 DISPLAY ' RES1=' RES1
000118 COMPUTE RES1 = 2 ** 64 DISPLAY ' RES1=' RES1
000119 COMPUTE RES1 = 2 ** 65 DISPLAY ' RES1=' RES1
000120 DISPLAY '--------------------------------'
000121 COMPUTE RES2 = 2 ** 62 DISPLAY ' RES2=' RES2
000122 COMPUTE RES2 = 2 ** 63 DISPLAY ' RES2=' RES2
000123 COMPUTE RES2 = 2 ** 64 DISPLAY ' RES2=' RES2
000124 COMPUTE RES2 = 2 ** 65 DISPLAY ' RES2=' RES2
000125 DISPLAY '--------------------------------'

Results:
-------------------------------
RES1=4611686018427387904
RES1=-9223372036854775808
RES1=0000000000000000000
RES1=0000000000000000000
-------------------------------
RES2=4611686018427387904
RES2=-9223372036854775808
RES2=0000000000000000000
RES2=0000000000000000000
-------------------------------
Cheers

--
Posted via a free Usenet account from http://www.teranews.com



.

Relevant Pages

  • Re: Perfrom Thru
    ... the American National Standard COBOL specification specifies no ... that these limits will vary from one implementation of American National ... I believe it is clear from the above that while the compiler may ... In order to resolve this issue, if the implementor has properly documented ...
    (comp.lang.cobol)
  • Re: Layout Hell-o
    ... layouts that were created on a single machine (with a single compiler). ... POSSIBLE that COMP in different file layouts were ...
    (comp.lang.cobol)
  • Re: Integers and standard
    ... But again, that's nothing the user chooses, but the implementor ... This assumes using the integer data type to represent a possibly non-integer data type. ... So long as the standard does nothing to prohibit my ability to use the integer data type to perform such programming (with the help of the compiler implementor), before we have a suitable bit/byte/whatever data type for the purpose, we should probably count ourselves lucky. ...
    (comp.lang.fortran)
  • Re: COMP vs. COMP-5
    ... COMP and a program that uses COMP-5 for *all* binary items regardless of TRUNC ... >>>> That is, if I'm confronted with a compiler that does not like COMP-5, ...
    (comp.lang.cobol)
  • Re: C function overloading?
    ... >> implementor of a steel hulled ship needs a rivet gun. ... Passengers are using the ship, just like I'm using the compiler. ...
    (comp.lang.c)