Db2 Packages Guide for COBOL Static SQL



Db2 packages hold prepared SQL and access paths.

A COBOL program with static SQL does not carry its access path inside the load module. During precompile, Db2 extracts embedded SQL into a DBRM. During bind, Db2 turns that DBRM into a package that records prepared SQL, bind options, authorization context, and the access path chosen for the SQL statements.

This refresh replaces the old C-oriented explanation with a Db2 for z/OS package guide for COBOL teams. It covers DBRMs, collections, packages, plans, BIND PACKAGE, REBIND, and the checks developers should make before promoting a static SQL change.

What Is a Db2 Package?

A Db2 package is a database object that contains the prepared form of static SQL statements from one program or routine. IBM's BIND PACKAGE documentation says the subcommand builds an application package, records the package description in catalog tables, and saves the prepared package in the directory.

For a COBOL application, the package is the Db2-side partner to the compiled and linked load module. If the load module and package do not match the same SQL level, the program can fail or run with the wrong assumptions.

COBOL Static SQL Build Flow

The build path matters because each output has a different job. The COBOL compiler handles host language code. Db2 handles embedded SQL through the DBRM and bind process.

Step	Output	Why it matters
Precompile	Modified COBOL source and DBRM	Separates SQL from COBOL source.
Compile and link-edit	Load module	Creates executable program code.
BIND PACKAGE	Package in a collection	Prepares static SQL and records access paths.
BIND PLAN or package list	Runtime plan reference	Connects run unit to packages.

DBRM, Package, Collection, and Plan

These four terms often get mixed together in incident calls. Keep them separate.

Term	Meaning	Common problem
DBRM	Database request module created by precompile.	Wrong DBRM library used during bind.
Package	Bound SQL from a DBRM or copied package.	Package not rebound after SQL or statistics change.
Collection	Named group that contains packages.	Runtime points to the wrong collection.
Plan	Runtime object that can include a package list.	Plan does not include the expected package collection.

BIND PACKAGE Example

Site JCL and options vary, but a package bind normally identifies the collection, DBRM member, action, owner or qualifier options, isolation level, and validation behavior.

BIND PACKAGE(ACCTCOLL) -
     MEMBER(ACCTPOST) -
     ACTION(REPLACE) -
     QUALIFIER(ACCT) -
     ISOLATION(CS) -
     VALIDATE(BIND) -
     EXPLAIN(YES)

Do not copy bind options blindly. ISOLATION(UR), RELEASE(DEALLOCATE), VALIDATE(RUN), and REOPT can be correct in one workload and wrong in another. Use the site standard unless there is a documented reason to deviate.

Package and Access Path

For static SQL, the access path is selected at bind or rebind time. That is why a COBOL program can slow down after a package rebind even when source code did not change. New RUNSTATS, index changes, subsystem function level, bind options, and SQL changes can all affect the path.

• Capture EXPLAIN output when binding important packages.
• Record the DBRM library, collection, package, and version used in the change.
• Compare access paths before and after a rebind for high-volume programs.
• Know the rollback option if the new package performs badly.

The related Db2 SQL Optimization Tips for COBOL Programs article covers access-path investigation in more detail.

REBIND PACKAGE

A rebind rebuilds an existing package using the current environment and selected options. It is common after RUNSTATS, index changes, SQL compatibility changes, or package maintenance. Rebind is powerful because it can improve performance without changing COBOL source, but it can also choose a worse path if statistics or options are wrong.

REBIND PACKAGE(ACCTCOLL.ACCTPOST) -
       APREUSE(WARN) -
       EXPLAIN(YES)

For production packages, make the rebind visible in the change record. Include package name, collection, owner, bind options, reason, expected benefit, and fallback plan.

Common Package Problems

Symptom	Likely package issue	Check
Program works in test but fails in production.	Different collection or missing package.	Plan PKLIST, collection, package name, and version.
SQL starts running slowly after maintenance.	Access path changed during rebind.	EXPLAIN before/after and RUNSTATS timing.
Authorization error appears at bind or run time.	Owner or VALIDATE option mismatch.	Package owner, binder authority, and object grants.
Old load module calls new SQL package.	Promotion mismatch.	Load library, DBRM, package timestamp, and change ticket.

Developer Checklist

• Confirm the DBRM was generated from the same source level as the load module.
• Confirm the package collection used by the runtime plan.
• Review bind options with the DBA for high-volume programs.
• Use EXPLAIN for SQL that can affect batch windows or online response time.
• Keep package rollback details in the implementation plan.
• Coordinate package changes with related DB2 Binding and Rebinding procedures.

FAQ

Is a Db2 package the same as a plan?

No. A package contains prepared SQL for a program or routine. A plan is a runtime object that can reference packages through a package list.

When should a package be rebound?

Rebind after relevant SQL, index, statistics, compatibility, or bind-option changes. For critical packages, compare access paths before and after the rebind.

Can a COBOL program run without its package?

No, static SQL needs the corresponding package or plan/package setup at runtime. The load module and Db2 package must be promoted together.

Package work is successful when the COBOL load module, DBRM, package collection, bind options, and access path all line up. Treat the package as part of the application deliverable, not an afterthought.