Using Db2 packages

Using packages is the best way to ensure that the relationship between CICS® transactions and Db2® plans is easy to manage.

In early releases of Db2, before packages were available, the DBRMs from all the programs that could run under a particular CICS transaction had to be directly bound into a single plan. Changing one DBRM in a plan (because the SQL calls for that program had changed) required all the DBRMs in the plan to be bound again. Binding a large plan can be very slow, and the entire transaction is unavailable for processing during the operation. Just quiescing an application can be very difficult for a highly used one, but to leave the plan out of commission for an extended time while it is being rebound is usually unacceptable.

Dynamic plan exits were an interim solution designed to address this problem. The dynamic plan exit is an exit program that you specify in the DB2CONN or DB2ENTRY definition instead of specifying a plan name. You create many small plans for your CICS applications, each containing the DBRMs from a few programs, and the exit program selects the correct plan when each unit of work begins. You can also use the dynamic plan exit to switch between plans within a transaction. However, each small plan must still be rebound and taken out of commission every time an SQL statement changes in one of the programs that uses it. Also, the use of dynamic plan switching requires an implicit or explicit CICS SYNCPOINT to allow switching between plans.

Now that packages are available in Db2, using them is the best way to manage your plans. With packages, you can break the program units into much smaller parts, which you can rebind individually without affecting the entire plan, or even affecting the current users of the particular package you are rebinding.

Since updating a plan is easier with packages, you can build much larger applications without the need to switch transactions, programs, or plans to accommodate Db2 performance or availability. This also means that you do not have to maintain as many RDO definitions. You can also avoid situations where you might otherwise use dynamic SQL to obtain program flexibility. In a plan, you can even specify packages that do not exist yet, or specify package collections to which you can add packages. This means that DBRMs from new programs could be added without disturbing the existing plan at all.

The qualifier option on packages and plans to reference different table sets can give you more flexibility to avoid plan switching.

In summary, packages:
  • Minimize plan outage time, processor time, and catalog table locks during bind for programs that are logically linked together with START, LINK, or RETURN TRANSID and have DBRMs bound together to reduce DB2ENTRY definitions.
  • Reduce CICS STARTS or exits.
  • Avoid cloning CICS and DB2ENTRY definitions.
  • Provide the ability to bind a plan with null packages for later inclusion in the plan.
  • Allow you to specify collection at execution time using SET CURRENT PACKAGESET= variable , which is a powerful feature when used with QUALIFIER
  • Provide the QUALIFIER parameter, which adds flexibility to:
    • Allow you to reference different table sets using unqualified SQL
    • Reduce the need for synonyms and aliases
    • Lessen the need for dynamic SQL
There are other benefits that using packages can provide in a CICS environment:
  • It allows you to use fewer plans.
  • It allows you to bind low-use transactions into a single plan.
  • It increases thread reuse potential.

You can also optimize your application by using package lists that order their entries to reduce search time or by keeping package list entries to a minimum.

Db2 also provides accounting at the package level. For more information about packages, refer to the discussions of planning to bind and preparing an application program to run in the Programming for Db2 for z/OS in Db2 for z/OS product documentation and the IBM® Redbooks® publication, Db2 9 for z/OS® : Packages Revisited .