If you need to create plans for an application that has already been developed

Use this technique if the applications were developed with little attention to the Db2® plan aspects. After the application is completely developed, the plans are defined to match the transaction.

About this task

In general, defining plans after the application has already been developed is not recommended, but this technique is useful for conversion projects, where the application design is unchanged but the application now uses Db2.

The advantages and disadvantages of this technique completely depend on the actual application design and the result of the steps.

Procedure

When defining the Db2 plans and the DB2ENTRY specifications, you can perform the following steps:

For each program module with SQL calls, analyze under which CICS transaction codes they might run.
It is likely that a given program module is used under more than one CICS transaction code.
The output from this step is a list of DBRMs for each transaction.
For each CICS transaction code, decide on a plan that it should use.
Only one plan may be specified in the DB2ENTRY for a given CICS transaction code. More than one transaction may use the same plan.
For this step you have many alternatives. The possible number of plans to use is between one and the number of different transaction IDs. The best way to manage the plans is to use packages, binding all the DBRMs into packages that are then listed in plans. For details, see Using Db2 packages.

If you do not use packages, alternative techniques are described in Using one large plan for all transactions, Using many small plans, and Using plans based on transaction grouping.

Example

Applied to the example in Figure 1, a possible solution would be:

One plan, PLAN0, using the DBRMs from P0, P1, P2, P3, and PB, used by the transaction ID TRX0
One plan, PLANA, using the DBRMs from PA, PB, PC, and PD, used by the transaction ID TRXA
Two DB2ENTRY definitions, one for each plan