Plan and Package

In Simple terms, PLAN is executable, but package is not.

A package contains control structures that DB2 uses when it runs SQL statements. Packages are produced during program preparation. You can think of the control structures as the bound or operational form of SQL statements. All control structures in a package are derived from the SQL statements that are embedded in a single source program.

An application plan relates an application process to a local instance of DB2, specifies processing options, and contains one or both of the following elements:

• A list of package names


• The bound form of SQL statements

Some info related to PLAN and PACKAGE:
* Regardless of what the plan contains, you must bind a plan before the applicationcan run.
* You cannot bind or rebind a package or a plan while it is running. However, you can bind a different version of a package that is running.
* Input to binding the plan can include DBRMs only, a package list only, or a combination of the two.

Advantages of PACKAGEs: (Ref: DB2 Application Programming and SQL Guide)

1. Ease of maintenance: When you use packages, you do not need to bind the entire plan again when you change one SQL statement. You need to bind only the package associated with the changed SQL statement.

2. Incremental development of your program: Binding packages into package collections allows you to add packages to an existing application plan without having to bind the entire plan again. A collection is a group of associated packages. If you include a collection name in the package list when you bind a plan, any package in the collection becomes available to the plan. The collection can even be empty when you first bind the plan. Later, you can add packages to the collection, and drop or replace existing packages, without binding the plan again.
(Read the above, it will tell you what is COLLECTION).

3. Versioning: Maintaining several versions of a plan without using packages requires a separate plan for each version, and therefore separate plan names and RUN commands. Isolating separate versions of a program into packages requires only one plan and helps to simplify program migration and fallback. For example, you can maintain separate development, test, and production levels of a program by binding each level of the program as a separate version of a package, all within a single plan.

4. Flexibility in using bind options: The options of BIND PLAN apply to all DBRMs bound directly to the plan. The options of BIND PACKAGE apply only to the single DBRM bound to that package. The package options need not all be the same as the plan options, and they need not be the same as the options for other packages used by the same plan.

5. Flexibility in using name qualifiers: You can use a bind option to name a qualifier for the unqualified object names in SQL statements in a plan or package. By using packages, you can use different qualifiers for SQL statements in different parts of your application. By rebinding, you can redirect your SQL statements, for example, from a test table to a production table.