Going into production: checklist for CICS DB2 applications

This checklist shows the tasks you need to perform after designing, developing, and testing an application, in order to put the application into production.

These tasks are highly dependent on the standards you have used in the test system. For example, the tasks to be performed are different if:

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.
Migrate 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 migrate the packages straight to the production system. See "Produce an application plan for the production system" below 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:
Compile and link-edit for the production system
To produce load modules: Table 10 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 10. Migrating 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 11 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, refer to DB2 Packages: Implementation and Use.

Table 11. Migrating 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.

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

Related concepts
Preparing CICS DB2 programs for execution and production
The CICS DB2 test environment
CICS DB2 program preparation steps
What to bind after a program change
Bind options and considerations for programs
CICS DB2 program testing and debugging
Tuning a CICS application that accesses DB2
[[ Contents Previous Page | Next Page Index ]]