DB2 Binding and Rebinding

Collections.

A collection is a group of associated packages. If a collection name is included in the package list when a plan is bound, any package in the collection becomes available to the plan. The collection can even be empty when the plan is first bound. Later, packages can be added to the collection, and existing packages can be dropped or replaced, without binding the plan again.

A collection is implicitly created at the first package bind that references a named collection. The name of the package is collection.packagename.

The CURRENT PACKAGESET special register allows package searches on specific collections and disregards any other DBRMs. The following example uses the special register to search only the certcol collection:

EXEC SQL SET CURRENT PACKAGESET = 'certcol'

Binding and Rebinding.

The BIND PACKAGE subcommand allows you to bind DBRMs individually. It provides the ability to test different versions of an application without extensive rebinding.

Even when DBRMs are bound into packages, all programs must be designated in an application plan for execution by local jobs. BIND PLAN establishes the relationship between DB2 and all DBRMs or packages in that plan. Plans can specify explicitly named DBRMs, packages, collections of packages, or a combination of these elements. The plan contains information about the designated DBRMs or packages and about the data the application program intends to use. The plan is stored in the DB2 catalog.

In addition to building packages and plans, the bind process.

Validates the SQL statements, using the DB2 catalog. During the bind process, DB2 checks the SQL statements for valid table, view, and column names. Because the bind process occurs as a separate step before program execution, errors are detected and can be corrected before the program is executed.

Verifies that the process binding the program is authorized to perform the data-accessing operations requested by your program's SQL statements. When the BIND command is issued, an authorization ID can be specified as the owner of the plan or package. The owner can be any one of the authorization IDs of the process performing the bind. The bind process determines whether the owner of the plan or package is authorized to access the data the program requests.

Selects the access paths needed to access the DB2 data that the program wants to process. In selecting an access path, DB2 considers indexes, table sizes, and other factors. DB2 considers all indexes available to access the data and decides which ones, if any, to use when selecting a path to the data. BIND PLAN and BIND PACKAGE can be accomplished using DB2I panels, the DSNH CLIST, or the DSN subcommands BIND PLAN and BIND PACKAGE.

Depending on how the DB2 application was designed, all DBRMs could be bound in one operation, creating only a single application plan. Or, you might bind some or all of your DBRMs into separate packages in separate operations. After that, the entire application must still be bound as a single plan, listing the included packages or collections and binding any DBRMs not already bound into packages.

Binding or Rebinding a Package or Plan in Use

Packages and plans are locked during binding and execution. Packages that run under a plan are not locked until the plan uses them. If you execute a plan and some packages in the package list are never executed, those packages are never locked.

A package or a plan cannot be bound or rebound while it is running. However, a different version of a package that is running can be bound.

A few methods are used for binding and rebinding packages and plans.

The BIND(ADD) option can be used for creating a new plan or package.

BIND(REPLACE) is used when the program has been changed.

REBIND is used when a program has not changed but perhaps an index has been added or RUNSTATS has been executed, and any access path changes need to be accounted for.

Several of the options of BIND PACKAGE and BIND PLAN can affect your program design. For example, a bind option can be used to ensure that a package or plan can run only from a particular CICS connection or a particular IMS region; this cannot be enforced in your code. An example follows:

BIND PLAN(CICSONLY)-
MEMBER(CERTDBRM)-
ACTION(ADD)-
ISOLATION(CS)-
OWNER(DB2USER1)-
QUALIFIER(DB2USER1)-
CACHESIZE(0)-
ENABLE(CICS)CICS(CON1)

Removing a Plan or Package

One way to remove a plan or a package is to use the FREE command. The FREE command removes the object from the catalog tables, and it will no longer be available for use. The following example frees all the packages in the CERTCL collection:

FREE PACKAGE (CERTCL.*)

A package can also be dropped using the DROP PACKAGE SQL statement. The following is an example of dropping the DB2CERT package:

DROP PACKAGE DB2USER.DB2CERT

Created with Artisteer