Using one large plan for all transactions

A straightforward way to avoid having to switch plans during a transaction is to use one large plan for all CICS® transactions that issue SQL calls.

For the example in Figure 1:
  • There is one plan, PLAN0, using the DBRMs from P0, P1, P2, P3, PA, PB, PC, and PD
  • In CICS, define one DB2ENTRY specifying PLAN0 plus a DB2TRAN per transaction ID required (unless a wildcard transaction ID can be specified). One DB2ENTRY gives the best overall thread utilization if protected threads are used.
Advantages
  • There are no restrictions regarding which program modules can be executed under any transaction ID. For example, it is possible that program P3 can transfer control to program PB. This does not require any changes for the plan or the definition in CICS.
  • Each DBRM exists in only one plan (PLAN0).
  • Thread reuse is easy to obtain. All transactions could use the same DB2ENTRY.
Disadvantages
  • The complete plan must be rebound for any Db2® program modification.
  • BIND can be time-consuming for large plans.
  • The BIND process cannot take place while the plan is in use. The plan is likely to be in use in a production system most of the time due to normal activity. In a test environment, the transaction rate is normally low, but programmers can use debugging tools that make the response times longer with conversational programs. This can effectively keep the thread and plan busy.
  • Db2-invoked REBIND (due to plan invalidation) allows no Db2 transactions to execute this plan.
  • There is no real information value in messages and statistics pointing out the plan name, because there is only one plan.
  • EDMPOOL must be large enough to cope with DBDs, SKCTs, and CTs and must allow some fragmentation. Remember that the plan segmentation feature allows Db2 to load into CTs only parts of the application plans being executed. Nevertheless, the header and directory parts of an application plan are loaded in their entirety into the SKCT (if not already loaded), then copied from the SKCT to CTs. This happens at thread creation time.

    Because the application plan directory size is directly dependent on the number of segments in the plan, using a large plan influences the EDMPOOL size and the number of I/O operations needed to control it.