DB2 BIND and REBIND: What They Do and When to Run Each



Binding turns static SQL into a runnable package.

A COBOL program with embedded SQL does not become runnable after compile alone. The SQL is precompiled into a DBRM, bound into a package, connected to a plan or package list, and then used by the job, CICS transaction, or IMS program at runtime.

This refresh explains Db2 binding and rebinding for mainframe developers: what BIND does, why REBIND is used, how collections and package sets affect runtime lookup, and what to check before promoting a changed program.

Where Binding Fits in a COBOL Db2 Build

A typical static SQL build has these steps:

1. Precompile the COBOL source and extract SQL into a DBRM.
2. Compile the modified COBOL source.
3. Link-edit the load module.
4. Bind the DBRM into a package.
5. Bind or use a plan that includes the package.

If the package is missing or the plan cannot find it, the program can compile cleanly and still fail at runtime.

What BIND PACKAGE Does

BIND PACKAGE takes a DBRM and creates a package. During bind, Db2 validates SQL, checks object names, checks authorization, and selects an access path for static SQL statements.

BIND PACKAGE(CERTCOL)
     MEMBER(CERTPGM)
     ACTION(REPLACE)
     ISOLATION(CS)
     OWNER(DB2USER1)
     QUALIFIER(DB2USER1)

The package becomes the stored form of the program's static SQL. The access path chosen at bind time can change when statistics, indexes, SQL text, or bind options change.

What BIND PLAN Does

A plan is the runtime object that lets an application execute Db2 SQL. Modern static SQL designs usually bind DBRMs into packages and then bind a plan that references package collections through PKLIST.

BIND PLAN(CERTPLAN)
     PKLIST(CERTCOL.*)
     ACTION(REPLACE)
     ISOLATION(CS)

Using package lists means packages can be added or replaced in a collection without rebinding the plan every time.

Collections and Package Names

A collection is a group of associated packages. A package name is commonly referenced as collection.package. The collection is implicitly created the first time a package is bound into that collection.

Collections are useful for separating environments or application versions. For example, test packages can use CERTCOL while production packages use a different collection name.

CURRENT PACKAGESET

The CURRENT PACKAGESET special register can direct package lookup to a specific collection for dynamic package resolution scenarios. Older applications sometimes use it to force package searches into a chosen collection.

EXEC SQL
    SET CURRENT PACKAGESET = 'CERTCOL'
END-EXEC.

Use this carefully. If the collection name is wrong, the application can fail even when the package exists somewhere else.

What REBIND Does

REBIND rebuilds an existing package or plan without changing the source program. It is commonly used after RUNSTATS, index changes, catalog changes, or Db2 maintenance when access paths need to be refreshed.

REBIND PACKAGE(CERTCOL.CERTPGM)

REBIND can change access paths. That is useful when statistics have improved, but risky when a critical batch job depends on a stable path. Review high-risk packages before rebinding in production.

BIND ADD, BIND REPLACE, and REBIND

Action	Use when	Common risk
ACTION(ADD)	Creating a new package or plan.	Fails if the object already exists.
ACTION(REPLACE)	Program SQL changed and the package must be replaced.	Can replace the wrong collection member if naming is sloppy.
REBIND	Program did not change, but access path or bind options need refresh.	Can change a stable access path after statistics or index changes.

Binding While a Package Is in Use

Packages and plans can be locked during execution and bind processing. A package or plan generally cannot be rebound while the same object is actively running. A different package version, however, can be bound depending on how versioning and collections are set up.

This is why batch windows and CICS availability matter. Rebinding a package used by a high-volume transaction is not the same as rebinding a rarely used report package.

Bind Options That Affect Programs

Bind options can affect runtime behavior. Some options control isolation, ownership, qualifier resolution, package lookup, and environment restrictions.

BIND PLAN(CICSONLY)
     PKLIST(CERTCOL.*)
     ACTION(REPLACE)
     ISOLATION(CS)
     OWNER(DB2USER1)
     QUALIFIER(DB2USER1)
     ENABLE(CICS)

These settings should be reviewed as deployment controls, not just DBA syntax.

Freeing or Dropping Packages

Use FREE to remove packages or plans from the catalog when they are no longer needed.

FREE PACKAGE(CERTCOL.*)

A package can also be removed with SQL in environments that support the statement and required authorization:

DROP PACKAGE DB2USER.DB2CERT

Do not remove a package just because a load module is old. Confirm runtime references, collection usage, and fallback needs first.

Promotion Checklist

• Confirm the DBRM member matches the COBOL source level.
• Bind into the correct collection.
• Confirm the plan or package list can find the package.
• Review changed access paths for high-volume SQL.
• Check authorization for the bind owner and runtime auth ID.
• Keep fallback package/version details for production rollout.

How Binding Relates to Packages

This article focuses on bind and rebind actions. For a wider explanation of package structure, collections, plans, DBRMs, and static SQL promotion, see Db2 Packages Guide for COBOL Static SQL.

For access-path checks after bind or rebind, see Db2 SQL Optimization Tips for COBOL Programs and Db2 Indexing.

FAQ

What is the difference between BIND and REBIND in Db2?

BIND creates or replaces a package or plan from DBRM input. REBIND rebuilds an existing package or plan, often to refresh access paths after statistics, index, or catalog changes.

Does REBIND require a COBOL program change?

No. REBIND is commonly used when the program did not change but Db2 should reconsider access paths or bind options.

Why do collections matter in Db2 packages?

A collection groups related packages and helps plans or package lookup find the correct package version at runtime.

Binding is not an afterthought after compile. It is the point where Db2 validates the SQL, checks authority, and chooses the access path your COBOL program will use.