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.
- 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.
- 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.

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:
- 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.
- 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.
- 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.

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.
Run time differences with Enterprise COBOL Version 5 or Version 6 programs
- 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.
Use 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.
- 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.
The
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
using
ACTION code 1. CEE3ABD
Your 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.

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
.

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.