Rational Developer for System z
Enterprise COBOL for z/OS, Version 4.1, Compiler and Runtime Migration Guide


Making application program updates

The following application programming tasks are necessary when upgrading your source. They should be performed in roughly the following order:

Save the existing source as a backup (a benchmark to compare to and a version to which to recover if the converted modules have problems).
  1. Update the job and module documentation.

    It is extremely important that all updates be properly documented. COBOL itself is reasonably self-documenting. However, keep a log of the compiler options you specify and the reasons for specifying them. Also document any special system considerations. This is an iterative process and should be performed throughout the conversion programming task.

  2. Update the available source code.

    Whenever possible, use the conversion tools described in Conversion tools for source programs. Otherwise, update the source code manually.

  3. Compile, link-edit, and run.

    After the source has been updated, you can process the program as you would a newly written Enterprise COBOL program. ( You need the Language Environment run time installed.)

  4. Debug.

    Analyze program output and, if the results are not correct, use Debug Tool or Language Environment dump output to uncover any errors.

  5. Test the converted programs
    After upgrading your source to Enterprise COBOL, set up a procedure for regression testing. Regression testing will help to identify:
    • Fixed file attribute mismatches (file status 39 problems). Verify that your COBOL record descriptions, JCL DD statements, and physical file attributes match. For more information, see Preventing file status 39 for QSAM files.
    • Dependency on WORKING-STORAGE being initialized to binary zeros. If you have WORKING-STORAGE zero dependency, specify the Language Environment STORAGE(00) runtime option.
    • Performance differences.
    • Sign handling problems—S0C7 abends. The data's sign must match the signs allowed by the NUMPROC compiler option suboption that you specify.
    • DATA(24) issues. Do not mix AMODE 24 programs with 31-bit data.
    After you have established a regression testing procedure, and after your programs run correctly, test them against a variety of data:
    • Locally: Each program separately
    • Globally: Programs in a run unit in interaction with each other

    In this way, you can exercise all the program processing features to help ensure that there are no unexpected execution differences.

  6. Repeat when necessary.

    Make any further corrections that you need, and then recompile, relink, rerun, and, if necessary, continue to debug.

  7. Cut over to production mode.

    When your testing shows that the entire application receives the expected results, you can move the entire unit over to production mode. (This assumes your production system is already using the Language Environment run time. If not, STEPLIB to the Language Environment run time. See Deciding how to phase Language Environment into production mode.)

    In case of unexpected errors, be prepared for instant recovery:
    • Under z/OS, run the old version as a substitute from the latest productivity checkpoint.
    • Under DB2 and IMS return to the last commit point and then continue processing from that point using the unmigrated COBOL program. (For DB2, use an SQL ROLLBACK WORK statement.)
    • For non-CICS applications, use your shop's backup and restore facilities to recover.
  8. Run in production mode.

    After cut over, monitor the application for a short time to ensure that you are getting the results expected. After that, your source conversion task is completed.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)