| ### Migrating COBOL applications

There are four host COBOL compilers currently supported by IBM: VS COBOL II Release 4, COBOL for MVS & VM Release 2, COBOL for OS/390™ & VM, and COBOL for VSE.

#### MVS and OS/390

A year 2000 ready language provides four-digit year dates, and for COBOL, only COBOL for MVS & VM ( or COBOL for OS/390 & VM) and and Language Environment are ready; there is no four-digit year date language in either of the "old COBOLs":

- OS/VS COBOL (no service support)
- VS COBOL II (service will end in 2001)

"Good grief," you say, "does that mean I have to re-compile my entire shop!?" Not necessarily.

1. First, service support for the old compilers may be gone or going, but support for your old COBOL-compiled programs is available indefinitely by using Language Environment.. With few exceptions you can migrate your old COBOL programs to Language Environment without even recompiling; it's a run-time only migration.
2. Second, old COBOL programs with no date-related logic require no source changes or recompiles. (Now you see why it's so important to analyze the impact to your programs.)
3. If your OS/VS COBOL applications do have date-related logic, you will have to examine them for possible year 2000 impacts. If updating is needed, you need to use the COBOL for MVS & VM or the COBOL for OS/390 & VM compiler.

#### Recommendations

Ideally, programs should be compiled with a supported compiler (COBOL for MVS & VM or COBOL for OS/390 & VM) and run with a supported run-time library (Language Environment for MVS & VM or OS/390 Language Environment). Thus the safest solution is to migrate all programs to one of these supported compilers before making year 2000 updates. The minimum solution is to move all programs to run under Language Environment before starting your year 2000 work. This move guarantees long-range run-time support, and having the ANSI 85 features makes your year 2000 work easier. This ideal state can be reached gradually in a fully supported manner:

- Run-time migration followed optionally at some future date by
- Compiler migration

Because a module compiled with COBOL for MVS & VM or COBOL for OS/390 & VM can call a module compiled with VS COBOL II in the same run unit, and vice versa, you can migrate your VS COBOL II programs gradually to COBOL for OS/390 & VM. VS COBOL II Release 3 and later programs are supported under Language Environment.

The safest year 2000 solution for old COBOL programs that are not migrated is to call a COBOL for OS/390 & VM subprogram that uses an intrinsic function for year 2000 support. A minimum year 2000 solution for old COBOL programs begins with a windowing or compression approach and requires adding some logic after an ACCEPT FROM DATE statement to interpret the two-digit year field.

If you want to use COBOL language to get four-digit dates, use the date/time intrinsic functions of COBOL for OS/390 or COBOL for OS/390 & VM. To get four-digit-year dates using any older compiler,

- Call a simple assembler or C routine to use SVC 11 (non-CICS only)
- Under CICS, use EXEC CICS FORMATTIME or assembler with STCK instruction
- Run VS COBOL II programs under Language Environment and use dynamic calls to access those date/time services.

Although not recommended, it is possible to call the IBM-supplied 4-digit date routine IGZEDT4 from VS COBOL II programs (or from OS/VS COBOL programs by calling a VS COBOL II subprogram that calls IGZEDT4). PTF PN76666 is required to enable IGZEDT4, which returns the current date in the form YYYYMMDD.

    CALL 'IGZEDT4' USING BY REFERENCE date-identifier

Note: IGZEDT4 is not supported under CICS or under VSE.

The net is: migrate to COBOL for MVS &VM, if possible, but at least move to Language Environment.

##### Recommendations for VSE

The above recommendations also hold true for programs compiled with the DOS/VS COBOL and VS COBOL II compilers running on VSE, except that the strategic run-time library is Language Environment for VSE. For more information on COBOL and VSE, check out VSE and Year 2000 -- COBOL and LE support and The IBM COBOL family for VSE.

##### More technical grit on libraries

Every COBOL program requires library routines in order to execute. They may be statically linked to the load modules or dynamically accessed at execution time. When the library routines being used are supported by IBM service, you can call IBM service when there is a problem. For example, the library routines for OS/VS COBOL programs exist in the OS/VS COBOL run-time library, the VS COBOL II run-time library, and in the Language Environment run-time library.

If your OS/VS COBOL programs are running using the OS/VS COBOL library, they are not supported by IBM service. If your OS/VS COBOL programs are running using the Language Environment run-time library, your programs are supported by IBM service and will be supported into the 21st century.

For your load modules of programs compiled with the NORES option and link-edited with the OS/VS COBOL library or the VS COBOL II library, you need to use REPLACE linkage editor control statements to replace the old library routines with the Language Environment versions. If you start with object programs (not linked), you simply need to link edit with Language Environment. If the programs were compiled with RES, you can simply make the Language Environment library routines available at execution time, in place of the OS/VS COBOL or VS COBOL II library routines, by using LNKLST or STEPLIB on MVS, and GLOBAL statements on VM.

A recompile is not required to complete your migration.

#### More migration help

You can use the Edge Portfolio Analyzer to determine what compiler was used to create a given load module and even what options were used..

For more help and greater detail on migrating your old programs, see COBOL Migration Guide and Language Environment Run-Time Migration Guide. Also, check the COBOL Qs&As -- your question may be answered there.

©1997 IBM Corporation