Making application program updates
The following application programming tasks are necessary when upgrading your source. They should be performed in roughly the following order:
- 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.
- Update the available source code.
Whenever possible, use the conversion tools described in Conversion tools for source programs. Otherwise, update the source code manually.
- Compile, bind (link-edit), and run.
It is recommended that you compile and test two times. The first time, compile with SSRANGE, NUMCHECK, PARMCHECK, INITCHECK, and OPT(0); and then after a successful test, recompile with NOSSRANGE, NONUMCHECK, NOPARMCHECK, and OPT(2), for production.
It is also recommended that you recompile all programs in an application as you upgrade. This way you will shake out all possible problems and also get the maximum performance benefit of Enterprise COBOL V5 or V6.
After the source has been updated, you can process the program as you would a newly written Enterprise COBOL program.
- Debug.
Analyze program output and, if the results are not correct, use Debug Tool or Language Environment® dump output to uncover any errors.
- Test the converted programs.
Compare results of the newly recompiled version of the application with the existing version of the application to make sure that the results are the same. Some customers have used the code coverage feature of Debug Tool to make sure that their programs have the same behavior with COBOL V5 or V6 as they did with previous COBOL compilers, as well as comparing output of the 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.
- 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.
- Repeat when necessary.
Make any further corrections that you need, and then recompile, relink, rerun, and, if necessary, continue to debug.
- 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 you have completed your migration to Language Environment. )
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.
- 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.