Using many small plans

Using many small plans requires many transaction IDs, each of which has a corresponding plan. This technique reduces plan sizes and plan overlap.

You are recommended to use packages rather than using many small plans.

Using many small plans implies either that the program flow follows a narrow path with limited possibilities for branching out, or that plan switching takes place frequently.

In the example in Figure 1, the switching could take place between program P0 and the programs at the next lower level, or between program PA and the programs at the next lower level.

PLAN1 for (TRX0) using the DBRMs from programs P0, P1, P2, and P3.
PLANA for (TRXA) using the DBRMs from programs PA, PB, PC, and PD.

However, program P3 can transfer control (using the XCTL command) to program PB. A plan switching technique must then be used.

A special variation of using small plans exists. In some applications, it can be convenient to have the terminal user specify the transaction ID for the next transaction. It is typically in read-only applications, where the user can choose between many different information panels by entering a systematically built 1- to 4-character transaction ID. The advantage for the user is the ability to jump from any panel to any other panel without passing a hierarchy of submenus.

If a Db2® plan is associated with each transaction ID, the application ends up with many small plans.

Advantages

Plan maintenance is relatively simple, because little overlap exists between plans.
High information value in messages, statistics, and so on, pointing out the plan name.

Note: Packages offer these advantages, too.

Disadvantages

Plan switching occurs often, unless the application flow follows a narrow path.
It is difficult to use protected threads, because the transactions are spread over many sets of transaction IDs, plans, and threads.
Resource consumption can be high, due to plan switching and low thread reuse.

Note: Packages avoid these disadvantages.