Several things have come together to give us a better recommendation for customers who want to migrate to Enterprise COBOL V5 and V6 but who also want to avoid discovering 'differences' when they deploy into production. 

First, some background.  As usual, read the COBOL Migration Guide, especially the Migration Checklist (Chapter 3):
http://www-01.ibm.com/support/knowledgecenter/SS6SG3_5.2.0/welcome.html

Second, some of the most difficult problems when migrating to COBOL V5 (and V6) are not caused by changes in the COBOL language supported by COBOL Version 5 and V6, but instead are caused by 'invalid COBOL data' that cannot be detected by inspecting source code.

The top six most common of these are:
o Invalid data in numeric USAGE DISPLAY data items
o Parameter/argument size mismatch:
o Modifying data outside the bounds of a table
o Using tables when the ODO object value is not in the legal range
o Modifying data following a table with INDEXED BY indexes
o Overpopulated data items, with values that have more digits than are defined in the data definitions
 

Invalid COBOL data can be a migration challenge

Enterprise COBOL for z/OS V5 and V6 generate different hardware instructions to do the same work as COBOL V4 and earlier compilers.  As a result, some customers can get different results with COBOL V5 and V6 compared to previous compilers.  IBM has compiler options that can help you find and fix these migration problems. We also have a new migration recommendation with invalid COBOL data in mind which is as follows:.

In order to find and fix these cases of invalid COBOL data, we recommend that users:

• Always compile with RULES(NOEVENPACK) and DIAGTRUNC compiler options
• Use the "Scanning COBOL programs for compatibility" feature of RDz 9.5 to check parameters and arguments
• Compile with SSRANGE, ZONECHECK and OPT(0) for initial code changes and unit test
• If the initial tests go well, then:
  • - Recompile with NOSSRANGE, NOZONECHECK and OPT(2) for quality assurance test and production

1. If the initial tests show invalid COBOL data, then there are 2 choices:
   1. Fix the code or data to make sure data items have valid COBOL data at runtime or
   2. Use ZONEDATA or other options to try and tolerate the bad data.  Using ZONEDATA, for example, will reduce optimization, but can provide similar results as previous compilers when working with invalid COBOL data.

 
Finally, in the topic of "Before you buy COBOL V5 (or V6)", we recommend the following:
- Install the latest maintenance on LE and other products for COBOL V5

              (Use the COBOL V5 FIXCAT feature as documented here: http://www-01.ibm.com/support/docview.wss?uid=swg21648871. )

- Change build processes to add REPLACE -IMMED,IGZEBST as the last control statement in the BIND/LINK step to aid in fixing the "old VS COBOL II bootstrap" problem.  It will not fix all cases, but it is risk-free with possible benefits. In some cases, REPLACEing IGZEBST is required.

     Replacing IGZEBST is REQUIRED in these cases:
          1) if the IGZEBST modules are not from LE, or are from the VS COBOL II runtime and PN74000 is not installed
                       on the IGZEBST modules (bind/link-edit with REPLACE required), or
          2) if in CICS and static calls to VS COBOL II and PI33330 is not installed on the IGZEBST modules

                       (bind/link-edit with REPLACE required)

      In the following case old IGZEBST can cause a problem until a PTF is installed:
          3) If in CICS and have dynamic calls to VS COBOL II and PI25079 is not installed on SCEERUN (no link or relink needed)

- Convert PDS load libraries to PDSE
- Locate all OS/VS COBOL programs and either target them for early migration to V5 or migrate to V4 now

- While using COBOL V4.2 you can start finding and fixing cases of invalid COBOL data by: 

     >Using the "Scanning COBOL programs for compatibility" feature of RDz 9.5 to check parameters and arguments
     > Compiling with SSRANGE, ZONECHECK and NOOPT for initial code changes and unit test
        YES, ZONECHECK is now available for COBOL V4.2!  See APAR PI42333 and PTF UI32232
     > Recompiling with NOSSRANGE, NOZONECHECK and OPT(2) for quality assurance test and production

Tom

Another situation that arises is using uninitialized data.  Using uninitialized LOCAL-STORAGE items was likely always a problem in previous versions of COBOL.  WORKING-STORAGE is allocated differently with COBOL V5;  it does not necessarily come from the heap.  That means that using LE options to initialize heap storage doesn't always initialize WORKING-STORAGE.

That's interesting. Can you outline the type of situation where the compiler would make the distinction, where WORKING-STORAGE would be heap, and where it would not (and where it is, when not heap)?

Just share some information here for others who's also searching the same topic.

The migration guide has some statements about the HEAP & STORAGE behavior. 

HEAP In some cases, WORKING-STORAGE space is not acquired from HEAP and therefore the HEAP (and STORAGE) option has no effect.
WORKING-STORAGE is acquired from HEAP when the COBOL program is compiled with the RENT option and is in one of the following cases:
       - Compiled with Enterprise COBOL V4.2 or earlier releases
       - Compiled with the DATA(24) compiler option
       - Running in CICS
       - A COBOL V5.1.1 in a program object that contains only COBOL programs (V5.1.1, V4.2 or earlier) and assembly programs. There are  no Language Environment interlanguage calls within the program object and no COBOL V5.1.0 programs.
       - A COBOL V5 program in a program object where the main entry point is COBOL V5. In this case, the program object can contain Language Environment interlanguage calls, with COBOL statically linking with C, C++ or PL/I. All COBOL V5 programs within such program objects (even if they are not the main entry point) have their WORKING-STORAGE allocated from heap storage.

In cases where WORKING-STORAGE is not obtained from HEAP,storage tuning using the HEAP option no longer improves performance. In fact, acquiring a large HEAP to avoid repeated requests for HEAP storage is detrimental to COBOL V5.1 program performance in these cases.