Topic
  • No replies
SystemAdmin
SystemAdmin
403 Posts

Pinned topic Special register TALLY in compiler 4.2

‏2011-08-30T07:19:31Z |
It seems to have changed.. the documentation has always said:

01 TALLY GLOBAL PICTURE 9(5) USAGE BINARY VALUE ZERO.

..and COMP is described as follows..

9(5) through 9(9) ø Binary fullword (4 bytes) ø 0 through 4,294,967,29

Now.. our programs which were compiled with TRUNC(OPT) in version 4.1 are now doing endless loops after recompile with version 4.2 (also with TRUNC(OPT) because TALLY is wrapping at 99999.

Is this the expected behaviour?
Updated on 2011-08-30T10:58:01Z at 2011-08-30T10:58:01Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    403 Posts

    Re: Special register TALLY in compiler 4.2

    ‏2011-08-30T07:54:39Z  
    It's not isolated to the TALLY register - seems like TRUNC(OPT) has changed how

    PICTURE 9(5) USAGE BINARY

    is enterpreted in a statement like:

    PERFORM VARYING TALLY FROM 1 BY RECL
    UNTIL TALLY > (ARKIV-DATA-LENGTH)

    Where ARKIV-DATA-LENGTH is PIC S9(9) COMP-5
  • SystemAdmin
    SystemAdmin
    403 Posts

    Re: Special register TALLY in compiler 4.2

    ‏2011-08-30T10:58:01Z  
    It's not isolated to the TALLY register - seems like TRUNC(OPT) has changed how

    PICTURE 9(5) USAGE BINARY

    is enterpreted in a statement like:

    PERFORM VARYING TALLY FROM 1 BY RECL
    UNTIL TALLY > (ARKIV-DATA-LENGTH)

    Where ARKIV-DATA-LENGTH is PIC S9(9) COMP-5
    I was too quick to conlude that it was the COBOL compiler - it was the DB2 preprocessor which at the same time was upgraded to version 10 - and it apparently produces a COBOL LENGTH field for a CLOB as COMP-5 (ARKIV-DATA-LENGTH in the expample) whereas our DB2 v9 produced a COMP field.

    This makes the loop I showed "malfunction" with any COBOL compiler version I had available.