Binding an application plan

An application plan can include package lists.

About this task

To bind an application plan, use the BIND PLAN subcommand with at least one of the following options:

MEMBER
Start of changeSpecify this option to bind DBRMs to a package and then bind the package list to a plan. After the keyword MEMBER, specify the member names of the DBRMS.End of change
PKLIST
Specify this option to include package lists in the plan. After the keyword PKLIST, specify the names of the packages to include in the package list. To include an entire collection of packages in the list, use an asterisk after the collection name. For example, PKLIST(GROUP1.*).

The resulting plan consists of the following information:

  • Any programs that are associated with DBRMs in the MEMBER list
  • Any programs that are associated with packages and collections that are identified in PKLIST
Specifying the package list for the PKLIST option of BIND PLAN:

The order in which you specify packages in a package list can affect run time performance. Searching for the specific package involves searching the DB2® directory, which can be costly. When you use collection-id.* with the PKLIST keyword, you should specify first the collections in which DB2 is most likely to find a package.

For example, assume that you perform the following bind: 
BIND PLAN (PLAN1) PKLIST (COLL1.*, COLL2.*, COLL3.*, COLL4.*)
Then you execute program PROG1. DB2 does the following package search:
  1. Checks to see if program PROG1 is bound as part of the plan
  2. Searches for COLL1.PROG1.timestamp
  3. If it does not find COLL1.PROG1.timestamp, searches for COLL2.PROG1.timestamp
  4. If it does not find COLL2.PROG1.timestamp, searches for COLL3.PROG1.timestamp
  5. If it does not find COLL3.PROG1.timestamp, searches for COLL4.PROG1.timestamp.
When both special registers CURRENT PACKAGE PATH and CURRENT PACKAGESET contain an empty string: If you do not set these special registers, DB2 searches for a DBRM or a package in one of these sequences:
  • At the local location (if CURRENT SERVER is blank or specifies that location explicitly), the order is:
    1. All packages that are already allocated to the plan while the plan is running.
    2. All unallocated packages that are explicitly specified in, and all collections that are completely included in, the package list of the plan. DB2 searches for packages in the order that they appear in the package list.
  • At a remote location, the order is:
    1. All packages that are already allocated to the plan at that location while the plan is running.
    2. All unallocated packages that are explicitly specified in, and all collections that are completely included in, the package list of the plan, whose locations match the value of CURRENT SERVER. DB2 searches for packages in the order that they appear in the package list.

    If you use the BIND PLAN option DEFER(PREPARE), DB2 does not search all collections in the package list.

If the order of search is not important: In many cases, the order in which DB2 searches the packages is not important to you and does not affect performance. For an application that runs only at your local DB2 system, you can name every package differently and include them all in the same collection. The package list on your BIND PLAN subcommand can read: 
PKLIST (collection.*)

You can add packages to the collection even after binding the plan. DB2 lets you bind packages having the same package name into the same collection only if their version IDs are different.

If your application uses DRDA access, you must bind some packages at remote locations. Use the same collection name at each location, and identify your package list as: 
PKLIST (*.collection.*)

If you use an asterisk for part of a name in a package list, DB2 checks the authorization for the package to which the name resolves at run time. To avoid the checking at run time in the preceding example, you can grant EXECUTE authority for the entire collection to the owner of the plan before you bind the plan.

  • How DB2 identifies packages at run time
    The DB2 precompiler or DB2 coprocessor identifies each call to DB2 with a consistency token. The same consistency token identifies the DBRM that the SQL statement processor produces and the package to which you bound the DBRM.
  • Specifying the location of the package that DB2 is to use
    When your program executes SQL statements, DB2 uses the value in the CURRENT SERVER special register to determine the location of the necessary package. If the current server is your local DB2 subsystem and it does not have a location name, the value in the special register is blank.
  • Specifying the package collection that DB2 is to use
    To ensure that DB2 uses the intended package collection and does not waste time searching, explicitly specify the package collection that you want DB2 to use.
  • Overriding the values that DB2 uses to resolve package lists
    DB2 resolves package lists by searching the available collections in a particular order. To avoid this search, you can specify the values that DB2 should use for package resolution.
Parent topic: Binding an application
Related tasks:
Improving performance for applications that access distributed data
Related reference:
BIND PLAN (DSN)
CURRENT PACKAGE PATH
CURRENT PACKAGESET