Adding Enterprise COBOL Version 5 or Version 6 programs to existing COBOL applications

When you add an Enterprise COBOL V5 or V6 program to an existing application, you are either recompiling an existing program with Enterprise COBOL V5 or V6 or including a newly written Enterprise COBOL V5 or V6 program.

Note: You should use this Migration Guide only if you have completed the runtime migration to Language Environment®. This means that the following conditions have been met:
  • The Language Environment data set SCEERUN is installed in LNKLST or LPALST.
  • There are no instances of COBLIB, VSCLLIB, or COB2LIB in LNKLST or LPALST.
  • There are no instances of COBLIB, VSCLLIB, or COB2LIB in JCL STEPLIB or JOBLIB statements or in CICS® startup JCL.
  • All statically bound runtime library routines for programs that are compiled with NORES have been REPLACEd with routines from Language Environment.
  • IGZEBST bootstrap modules for VS COBOL II programs that are compiled with RES were either linked with the VS COBOL II runtime version of IGZEBST that has APAR PN74000 applied, or IGZEBST was REPLACEd with IGZEBST from Language Environment.

If these steps have not been completed, please first complete all runtime migration activities in the Enterprise COBOL V4.2 Compiler and Runtime Migration Guide at http://publibfp.dhe.ibm.com/epubs/pdf/igy3mg50.pdf prior to following the steps here.

When you add Enterprise COBOL V5 or V6 programs to your existing applications, you have the ability to:
  • Upgrade your existing programs incrementally, as your shop's needs dictate
  • Use Language Environment condition handling

If you have a program object that includes a COBOL program linked with C, C++, or Enterprise PL/I programs, the program object has slightly different behavior when the COBOL program is changed to Enterprise COBOL V5 or V6. This occurs when such program objects are fetched (that is, using either C fetch or PL/I fetch) more than once. In the subsequent fetches, external and static variables in these other LE languages may retain their last used state, following COBOL rules, instead of getting their initial values. With prior versions of COBOL linked in, the C, C++ and PL/I programs would retain C/C++ or PL/I behavior.

Start of change

Using Language Environment with Enterprise COBOL V5 or V6 and VS COBOL II programs

When running a mixture of VS COBOL II programs and Enterprise COBOL V5 or V6 programs:

  • A current version of IGZEBST is required:Start of change
    • For statically CALLed programs in CICS, you will need to replace IGZEBST in applications with VS COBOL II programs with the IGZEBST from LE with the PTFs for APAR PI33330 installed.
      Note: IGZEBST from LE with the PTFs for APAR PI33330 installed can also be used with any COBOL programs VS COBOL II and later without COBOL V5 or V6 programs.
    • For dynamically CALLed CICS programs, you just need to install the PTFs for APAR PI25079 on SCEERUN.
      Note: For statically CALLed programs in non-CICS, performance will be better if you replace IGZEBST in applications with VS COBOL II programs with the IGZEBST from LE with the PTFs for APAR PI33330 installed. It is not required. There is no issue with IGZEBST for dynamically called programs in non-CICS for calling VS COBOL II programs from COBOL V5 or V6 programs.
    End of change
  • A current version of CEEBETBL, the Language Environment externals table, is required. If you are including object code bound some time ago with your new COBOL V5 or V6 object code, you might be indirectly including an old version of CEEBETBL.

    If the length of CEEBETBL you bind is less than x'28' (or the length of the CEEBETBL in the current SCEELKED library), it is old and needs to be replaced, or you will encounter runtime abends or a terminating runtime message.

    If you rebind older object code with COBOL V5 or V6 as part of your migration, it is recommended that you specifically INCLUDE a current copy of CEEBETBL prior to INCLUDEs of the older object code, taking care that you do not inadvertently make CEEBETBL the entry point.

End of change

AMODE restrictions with Enterprise COBOL Version 5 or Version 6 programs

AMODE 24 execution of Enterprise COBOL V5.2 or V6 programs is supported in all the same cases as in earlier Enterprise COBOL compilers.

Note: To run COBOL V5 or V6 programs with AMODE 24, you must compile all COBOL programs with Enterprise COBOL V5.1.1 or later versions; or Enterprise COBOL V4.2 or earlier versions. If any component of a program object is compiled with Enterprise COBOL V5.1.0, the program object must run in AMODE 31. COBOL programs that run with AMODE 24 must be linked with the binder option RMODE(24).

Run time differences with Enterprise COBOL Version 5 or Version 6 programs

You cannot mix Enterprise COBOL V5 or V6 programs with:
  • OS/VS COBOL programs. You must migrate to Enterprise COBOL. To find any OS/VS COBOL programs, you can:
    • Use the Debug Tool Load Module Analyzer to scan load libraries for OS/VS COBOL programs.
    • Start of changeUse the free COBOL Analyzer from http://cbttape.org/cbtdowns.htm to scan load libraries for OS/VS COBOL programs. It is named as File # 321 COBOL Analyzer from Roland Schiradin & post processor on that web page.End of change
    • Install the fix for APAR PM86742 to your Language Environment and look for a warning message about detected OS/VS COBOL programs at run time.
  • VS COBOL II NORES programs. You must migrate to Enterprise COBOL.

Start of changeThe ILBOABN0 interface for requesting an ABEND in a COBOL environment can be called dynamically with Enterprise COBOL V5 and later versions. When called by a program compiled with the Enterprise COBOL compiler, it will have the same result as calling Start of changeCEE3ABDEnd of change using ACTION code 1. End of change

Start of changeYour are strongly recommended to migrate and use the CEE3ABD interface, because the CEE3ABD interface provides extra flexibility to control the level of details provided in the CEEDUMP produced.End of change

Start of changeWhen your application is called by Enterprise COBOL programs, it might ABEND in an unexpected way if it has an older version of ILBOABN0 (before LE's SCEELKED) statically linked. To fix the unexpected ABEND, you can follow one of the advises below:
  • Migrate to CEE3ABD.
  • Relink your application with the REPLACE ILBOABN0 in the LINK step, against LE's SCEELKED.
  • Change the COBOL program to use dynamic call for ILBOABN0.
End of change

RMODE restrictions with Enterprise COBOL Version 5 or Version 6 programs

  • Reentrant programs may be RMODE 24 or RMODE ANY
  • Non-reentrant programs must be RMODE 24.