Going into production: checklist for CICS Db2 applications

The following discussion assumes that you use separate Db2 and CICS® subsystems for test and production.

Going into production implies performing the following activities:

Use DDL to prepare production databases

All DDL operations must run on the production Db2 system, using DDL statements from the test system as a base. Some modifications are probably needed, for example, increasing the primary and secondary allocations, as well as defining other volume serial numbers and defining a new VCAT in the CREATE STOGROUP statements.

Prepare DCLGEN

For COBOL and PL/I programs, you may have to run DCLGEN operations on the production Db2 system, using DCLGEN input from the test Db2 system.

Depending on the option taken for compilations (if no compilations are run on the production system), an alternative could be to copy the DCLGEN output structures from the test libraries into the production libraries. This keeps all information separate between test and production systems.

Precompile for the production system

If you have bound your programs into packages on the test system, you do not need to perform this step. You can move the packages straight to the production system. See "Produce an application plan for the production system" for details of how to do this. However, if you want to bind your programs directly into application plans, or if you want to bind the programs into packages on the production system, you need to put the DBRMs for the programs on the production system. You can either:

• Precompile CICS modules containing EXEC SQL statements on the production system, or
• Copy DBRMs from the test system to the production system libraries.

Compile and link-edit for the production system

To produce load modules:

• If the DBRMs were produced by precompiling on the production system, compile and link-edit the CICS modules on the production system; or
• If the DBRMs were copied, or if you are moving packages from the test system to the production system, copy the load modules from the test system to the production system libraries.

Table 1 shows a procedure you can use to copy a changed load module from a test system to a production system library, replacing the old version of the load module.

Table 1. Moving a changed program from the test environment to the production environment

Test system	Production system	Notes
	USER.PROD.LOADLIB(PGM3)	The original load module
USER.TEST.LOADLIB(PGM3)		The test load module
	USER.OLD.PROD.LOADLIB(PGM3)	The old version of the program is placed in other production library
	USER.PROD.LOADLIB(PGM3)	The new version of the program is placed in the production library

By selecting the production run library using the proper JCL, you can run either the old version or the new version of the program. Then the correct version of the package is run, determined by the consistency token embedded in the program load module.

Produce an application plan for the production system

If you have bound your programs into packages on the test system, you can copy the packages to the production system, including them in a collection that is listed in the application plan. When you copy a package to the production system, you do not need to bind the application plan on the production system again, as long as the package is included in a collection that is already listed in the application plan.

Table 2 shows a procedure you can use to copy a changed package from a test system to a production system library, replacing the old version of the package. This example uses the VERSION keyword at precompile time to distinguish the different versions of the packages. For a full explanation and use of the VERSION keyword, see Programming for Db2 for z/OS in Db2 for z/OS product documentation.

Table 2. Moving a changed package from the test environment to the production environment

Test system	Production system	Notes
	location_name. PROD_COLL.PRG3.VER1	The old version of the package
location_name. TEST_COLL.PRG3.VER2		A new version of the package is bound on the test system and then copied to the production system
	location_name. PROD_COLL.PRG3.VER1	The old version is still in the production collection
	location_name. PROD_COLL.PRG3.VER2	The new version is placed in the production collection

If you want to bind your programs directly into application plans, or if you want to bind the programs into packages on the production system, you must perform the bind process on the DBRMs that you have placed on the production system. If you are binding your programs directly into application plans, you must then bind all the application plans on the production system that involve those programs. See The bind process for more information on the bind process. Note that due to various factors, such as the sizes of tables and indexes, comparing the EXPLAIN output between test and production systems can be useless. Nevertheless, it is recommended that you run EXPLAIN when you first bind a plan on the production system, to check the Db2 optimizer decisions.

GRANT EXECUTE

You must grant users EXECUTE authority for the Db2 application plans on the production system.

Tests

Although no further tests should be necessary at this point, stress tests are useful and recommended to minimize the occurrence of resource contention, deadlocks, and timeouts and to check that the transaction response time is as expected.

CICS definitions

To have new application programs ready to run, update the following RDO definitions on the CICS production system.

• RDO transaction definitions for new transaction codes
• RDO program definitions for new application programs and maps
• SIT for specific Db2 requirements, if it is the first Db2-oriented application going into production
• RDO DB2ENTRY and DB2TRAN definitions for the applications. RDO DB2CONN definition if it is the first Db2-oriented application going into production. When defining the new transactions and application plans in the DB2ENTRY you can use unprotected threads to get detailed accounting and performance information in the beginning. Later, you can use protected threads as needed.

In addition, if RACF® is installed, you need to define new users and Db2 objects.