Error behavior changes for incorrect programs

Incorrect COBOL programs might behave differently with Enterprise COBOL V5 and V6 than with prior versions. You must consider more vigorous testing for migrating to Enterprise COBOL V5 or V6 than you did for migrating to Enterprise COBOL V4.

  • Programs that use unsupported (yet undiagnosed) COBOL language syntax.
  • Programs that move data to and from data items that at run time contain values not conforming to the PICTURE clause in the data description entry. For example:
    • A fullword binary item with picture S9(6) USAGE BINARY, which contains an oversize value of +123456789 (unless the TRUNC(BIN) option was specified)
    • A two-byte packed-decimal item with picture S99 PACKED-DECIMAL, which contains an oversize value of 123 (for example, 123C in hexadecimal).
    • A packed-decimal or zoned-decimal item that contains an invalid or non-preferred sign, which does not conform to the sign requirements of the data description entry.
  • Programs with undiagnosed subscript range errors (when the SSRANGE compiler option was not specified), that reference storage outside the storage allocation for the base data item.
  • Applications with low-level dependencies on specific generated code sequences, register conventions, or internal IBM® control blocks might behave differently with Enterprise COBOL V5 and V6 than with prior versions. The information such as PROGRAM-ID, COMPILED TIME, and COMPILED DATE included in the initialization code of Enterprise COBOL V4 or earlier is not included in the initialization code of Enterprise COBOL V5 or later, so the program it depends on might behave differently with Enterprise COBOL V5 and V6.
  • Not all incorrect programs are diagnosed as incorrect. For example, see the following program that sets the value of an ODO object to outside of the legal range:
    77 VAR1 COMP-3 PIC 9(3).
01 X.
   02 VAR2 PIC X OCCURS 0 to 1 depending on VAR1.

   MOVE 128 to VAR1 
   MOVE ALL 'C' to X *> This is illegal!
    Results:
    • For V2, V3 and V4: 128 bytes of 'C' were moved
    • For V5 and V6: 1 byte of 'C' and 127 bytes of junk were moved
  • Programs with parameter length mismatches:
    WORKING-STORAGE SECTION.
. . .
77 GRP1 PIC X(100). *> The last item in WORKING-STORAGE SECTION
PROCEDURE DIVISION.
. . .
   CALL 'SUBP' USING GRP1.

PROGRAM-ID. SUBP.
LINKAGE SECTION.
01 GRP2 PIC X(500).
PROCEDURE DIVISION USING GRP2
   MOVE 'STUFF' TO GRP2(300:20) *> This is illegal!
    Results:

    In the example above, GRP1 and GRP2 lengths do not match. The MOVE to GRP2 results in an overlay of storage following the last data item in WORKING-STORAGE in the calling program.

    • For V2, V3 and V4: The illegal MOVE did not result in a failure because there was usually unused storage after the last data-item in WORKING-STORAGE (see CALLER), so the overwrite went undetected.
    • For V5 and V6: The file control blocks immediately follow the last data-item in WORKING-STORAGE. Therefore, the file-status information in the CALLER gets overlaid, which can subsequently change the flow of the program.
  • Programs using zoned decimal data (numeric with USAGE DISPLAY) with bad zone bits in numeric comparisons. In this example, byte 3 of VAR2 is x'40' that has zone bits x'4', which is invalid; all zone bits must be x'F'. 
    WORKING-STORAGE SECTION.
01 VAR1 PIC X(5) VALUE '00 0'.              <* Value x'F0F040F0' 
   02 VAR2 REDEFINES VAR1 PIC 9(5).
. . .
   IF VAR2 = ZERO
      DISPLAY "EQUAL TO ZERO"
   ELSE
      DISPLAY "NOT EQUAL TO ZERO"
   END-IF.
    Results:
    • For V4 with NUMPROC(MIG) and V5.1 with OPT(0), the program displays "EQUAL TO ZERO"
    • For V4 with NUMPROC(PFD) or NUMPROC(NOPFD), and V5.1 with OPT(1) or OPT(2), the program displays "NOT EQUAL TO ZERO"

    If you have invalid digits, invalid sign codes, or invalid zone bits in your data, change your programs or systems so that your programs do not have invalid data in numeric data items at run time.

    When you have corrected your programs or systems, you can use the preferred NOINVDATA option. Only if you cannot contain this work and must continue to run with invalid data, consider the following choices for the INVDATA option:
    • If you used NUMPROC(MIG) with COBOL V4, use INVDATA(FORCENUMCMP, NOCLEANSIGN) and NUMPROC(NOPFD) with COBOL V6.
    • If you used NUMPROC(NOPFD) with COBOL V4, use INVDATA(NOFORCENUMCMP,CLEANSIGN) (or simply INVDATA) and NUMPROC(NOPFD) with COBOL V6.
    • If you used NUMPROC(PFD) with COBOL V4, use INVDATA(NOFORCENUMCMP,CLEANSIGN) (or simply INVDATA) and NUMPROC(PFD) with COBOL V6.
    Notes:
    • If you completed migration from COBOL V4 or earlier versions to COBOL V5 or V6 in the past and used the deprecated ZONEDATA(MIG) option in COBOL V5 or V6 and are satisfied with the behavior, use INVDATA(FORCENUMCMP, CLEANSIGN) instead of ZONEDATA(MIG).
    • IBM recommends that you correct your programs and/or data and use the NOINVDATA option.

    If your data doesn't always have the correct zone bits in zoned decimal data items, compile with the INVDATA(FORCENUMCMP) compiler option so that the zone bits will always be ignored.

  • For programs using zoned decimal data with invalid zone bits, the SEARCH ALL statement may produce different results between Enterprise COBOL V4 and later versions (V5 and V6.1). In Enterprise COBOL V6.2, the SEARCH ALL statement behaves according to the INVDATA option as described in the previous bullet. Use any legal form of the INVDATA option to produce the same behaviour as Enterprise COBOL V4 or earlier versions.
    When the COBOL V6.2 runtime library enablement PTF is applied to the Language Environment®, SEARCH ALL statement will behave according to the INVDATA option as described in the previous bullet. This is available for all COBOL V5 and 6 programs without recompilation. Use any legal form of the INVDATA option to produce the same behaviour as Enterprise COBOL V4 or earlier versions.
    Note: It is not always possible to entirely match the behaviour of the old compiler even with these options when faced with clearly invalid data.

    This only affects programs with invalid zoned decimal data. If there are no invalid zone bits, the SEARCH ALL statement produces the same result regardless of the setting of the INVDATA option.