Checklist for migration

Each task in the following checklist is recommended; you should perform each task in the order shown.

1. Learn about Language Environment.
   Ensure that you and other application programmers who will be involved in the migration effort are familiar with the features of Language Environment and the differences between your current runtime environment and the Language Environment runtime environment. You can get information about Language Environment from publications such as:

   • z/OS Language Environment Customization
   • z/OS Language Environment Concepts Guide
2. Take an inventory of the applications and vendor products you intend to run with Language Environment.
   • C, C++, COBOL, Fortran, PL/I, or Assembler programs
     For each program you intend to move to the Language Environment runtime environment, obtain the following information:

     • Version and release of the compiler that generated the program
     • Which COBOL programs were compiled with RES and which with NORES
     • Runtime options used and how they were specified
     • Which PL/I programs use the shared library and which ones do not
     • Which programs call, or are called by, assembler programs
     • Which applications contain interlanguage communication (ILC)
     • Which programs are used with CICS®, IMS™, DB2®, or other subsystems
     • Control statements used
     • Frequency and types of abends
     • Test cases required and available
     • Amount of storage used
     • Frequency of execution of reusable or common modules
     • Program execution time (processor (CPU) and elapsed)
   • Vendor tools, packages, and products
     • Ensure that all vendor tools, packages, and products run with Language Environment; any source code for the packages must also be compatible with your Language Environment-conforming compiler.
     • Ensure that any vendor code generators generate code that is compatible with your Language Environment-conforming compiler.
     • Ensure that vendor development tools and debuggers will not issue their own ESPIE or ESTAE, as Language Environment must get control first.
3. Prioritize programs.
   Determine the effort required to migrate each program and the order in which you will migrate them. Each program will require some level of effort to migrate, ranging from minimal testing to a code rewrite. Using the information from your inventory analysis, determine if each program:

   • Requires minimum, moderate, or extensive testing
   • Runs with Language Environment without change
   • Requires relinking with Language Environment
   • Must be recompiled with a Language Environment-conforming compiler, without change to the source code
   • Requires changes to the source code
   • Does not run with Language Environment

   After you have determined the effort required to migrate each load module, list your programs in the order you want to move them to Language Environment. You should consider the importance of each program and how often it is used.

   You should migrate applications that contain ILC after you have migrated any applications that contain only C, C++, COBOL, Fortran, or PL/I. (An application that contains assembler, but is otherwise created from one language, is not considered an ILC application in this information.) For information about compatibility considerations for ILC applications, see Migrating ILC applications to Language Environment.

4. Install Language Environment.
   Perform the following tasks, which can be done concurrently:

   • Change default runtime options as appropriate.

     To ensure that the Language Environment runtime results are compatible with your current runtime results, you will need to change some of the default settings for the runtime options. For a list of recommended settings, see z/OS Language Environment Customization.

   • Assess storage requirements.

     Storage requirements may be larger for Language Environment than for your current runtime environment. During conversion, you might need DASD for the Language Environment runtime library and for the runtime library that you are currently using. For information about Language Environment DASD requirements, see z/OS Program Directory.

     Virtual storage requirements for placing library routines above or below the 16M line may also increase, depending on which Language Environment storage options you specify. For recommended settings, see z/OS Language Environment Customization.

   • Determine how to phase-in the Language Environment runtime environment using a STEPLIB approach or by adding Language Environment to the LNKLST.

     Using the STEPLIB approach, you can gradually phase-in the Language Environment runtime environment. When you use STEPLIB statements to specify the Language Environment runtime environment, you can phase-in one region (CICS or IMS), batch (group of applications), or user (TSO) at a time. Although using STEPLIB means changing JCL, a gradual conversion can be easier than moving all of your applications at one time.

     When you add Language Environment to the LNKLST, it is available to all of your applications. Ensure all applications are functioning correctly with Language Environment before adding Language Environment to your LNKLST. You might consider temporarily adding Language Environment to the LNKLST until you have confirmed the applications work as intended.

5. Set up a regression testing procedure.

   To ensure that the Language Environment runtime results are compatible with your current runtime results, you will need to perform regression tests on all the programs you migrate. Run your applications in parallel with your current runtime environment and with the Language Environment runtime environment to confirm that the results are the same. You can temporarily add Language Environment to the LINKLST to accomplish this. When your applications are running with Language Environment in a test environment, you should take performance measurements, especially on any time-critical or response-critical applications.

6. Move applications into procedure.
   When your testing shows the entire application (or group of applications, if running more than one application in an IMS region or under TSO) runs as expected, you can move the entire unit over to production use. However, if an unexpected error occurs, you may need to perform one of the following steps:

   • On z/OS systems, run the previous version of your application as a substitute.
   • Under DB2, CICS, and IMS, return to the last commit point and then continue processing from that point using the previous version of the program. For DB2, use an SQL ROLLBACK WORK statement.
   • For batch applications, use the backup and restore facilities at your site to recover.

   After you move your applications to production use with the Language Environment runtime environment, monitor your applications to ensure that they continue to work properly. You can then run with the confidence that you had in your previous runtime library.