Db2 Binding an Application: COBOL DBRM, Package, Plan, and Run JCL



Bind the DBRM before the program runs.

A COBOL program with embedded SQL does not run against Db2 just because the load module was created. The SQL has to be precompiled into a DBRM, the program has to be compiled and link-edited, and Db2 must have a package or plan that matches what the program calls at run time.

That is the point of application binding. It connects the program's static SQL to Db2 access paths before the batch job, CICS transaction, or IMS program reaches production.

Where binding fits in the COBOL build

A typical static SQL build has four moving parts. If one of them is missing or from the wrong compile, the job can fail even when the COBOL source looks correct.

Build part	What it creates	Why it matters
Db2 precompile	Modified COBOL source and a DBRM member	The DBRM contains the static SQL that Db2 will bind.
COBOL compile	Object module	The embedded SQL calls have already been replaced with host-language calls.
Link-edit	Executable load module	The load module calls the Db2 language interface at run time.
Bind	Package and plan entries in Db2	Db2 stores executable forms of the SQL statements and the selected access paths.

Precompile creates the DBRM

The Db2 precompiler reads the COBOL source and finds each EXEC SQL block. It checks SQL syntax, handles host variable references, includes members such as SQLCA or DCLGEN copybooks when requested, and writes a DBRM member to a partitioned data set.

The DBRM is not the same as the COBOL object module. It is the Db2-side input for binding. In many shops the member name matches the program name, such as PAYRPT01, because that makes the bind JCL and promotion controls easier to audit.

//PC.SYSIN    DD  DSN=APP.SOURCE(PAYRPT01),DISP=SHR
//PC.SYSCIN   DD  DSN=APP.WORK.COBOL(PAYRPT01),DISP=SHR
//PC.DBRMLIB  DD  DSN=APP.DBRMLIB(PAYRPT01),DISP=SHR

Bind the package from the DBRM

For most production applications, bind the DBRM as a package and include the package in a plan. A package keeps the bind unit close to one program module, so a change to one COBOL program does not force every related DBRM in a large plan to be rebound.

BIND PACKAGE(APP01)
  MEMBER(PAYRPT01)
  ACTION(REPLACE)
  ISOLATION(CS)
  CURRENTDATA(NO)
  QUALIFIER(PROD)

The exact bind options depend on the shop standard and workload. For example, a read-only reporting program may use different lock and isolation choices from an update program that posts end-of-day financial rows. Do not copy a bind card from another application without checking the program's SQL behavior.

Bind the plan used by run JCL

The application plan tells the run command which packages can be used. A common pattern is to bind packages into a collection and then bind a plan with a package list.

BIND PLAN(PAYPLAN)
  PKLIST(APP01.PAYRPT01)
  ACTION(REPLACE)

Some sites use a wildcard package list such as APP01.* for a controlled collection. That can reduce plan maintenance, but it should still be managed by promotion rules so test packages do not accidentally become callable from production jobs.

Run JCL must point to the right plan

After compile, link-edit, package bind, and plan bind, the batch job still has to call the expected plan. A typical DSN run step names the Db2 subsystem, program, plan, and application load library.

//RUNSQL  EXEC PGM=IKJEFT01
//STEPLIB DD  DSN=DSN.V12.SDSNLOAD,DISP=SHR
//SYSTSIN DD  *
  DSN SYSTEM(DSN1)
  RUN PROGRAM(PAYRPT01) PLAN(PAYPLAN) -
      LIB('APP.PROD.LOADLIB')
  END
/*
//SYSPRINT DD SYSOUT=*

If the run step names an old plan, a test collection, or the wrong load library, the program may call a package that does not match the current DBRM. That is why a release checklist should compare the load module, DBRM member, package bind, plan bind, and run JCL before the job is released.

Common bind failures and runtime clues

Binding problems usually show up in the bind output, Db2 messages, or SQLCODE returned to the program. The exact message text matters, so always check the Db2 output from the failing job before changing bind options.

Symptom	Likely area to check
Bind fails because a table or view cannot be found	Check the qualifier, owner, current environment, and whether the object exists in that subsystem.
Bind fails because the user is not authorized	Check package, plan, table, view, and execute privileges for the bind owner.
Runtime SQLCODE points to package not found	Check package collection, plan package list, subsystem, and whether the package was promoted.
Runtime SQLCODE points to timestamp or consistency mismatch	Check whether the load module and DBRM/package came from the same precompile.

Application bind checklist

• Use the DBRM created from the same source version that produced the load module.
• Keep DBRM library, load library, package collection, and plan name visible in promotion records.
• Bind changed programs as packages instead of rebinding a large plan directly from many DBRMs.
• Review QUALIFIER, OWNER, VALIDATE, isolation, and current data options against the application type.
• Confirm the run JCL names the intended plan and load library before moving the job to production.

Related DB2 topics

Application binding sits close to several other Db2 topics. Review Db2 Binding and Rebinding for package and plan maintenance, Db2 Packages for package structure, Db2 Objects for database object context, and Db2 SQL Optimization Tips for COBOL Programs for access path review.

FAQ

Is a DBRM the same as a package?

No. The DBRM is produced by the precompile step. A package is created when Db2 binds that DBRM into the catalog and directory.

Can a COBOL Db2 program run without a bind?

A static SQL COBOL program needs a valid package or plan before it can run successfully against Db2. Dynamic SQL follows a different prepare path at run time.

Why does a program fail after a successful compile?

The compile only proves the host language build completed. The run can still fail if the DBRM was not bound, the plan does not include the package, or the load module and package do not match.

For production, treat bind output as part of the build evidence. A clean compile without the matching DBRM, package, plan, and run JCL is not enough.