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:
- There are separate DB2® systems for test and production
- Only one DB2 is used for both test and production.
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:
- 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 migrating packages from the test
system to the production system, copy the load modules from the test system
to the production system libraries.
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.
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.
- 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.

[[ Contents Previous Page | Next Page Index ]]