BIND and REBIND commands in DB2

How you run BIND and REBIND

These are DSN subcommands. Issue them from:

• A TSO DSN session in the foreground
• Batch IKJEFT01 with DSN in SYSTSIN (the usual production bind job)
• DB2I bind/rebind panels

Data sharing scope is group: bind once, every member can use the package or plan. IFCID 090 on other members may show SYSOPR running the same command. They are not -BIND operator commands and not utilities.

BIND PACKAGE

Builds an application package. Db2 records the description in the catalog and saves the prepared package in the directory. BIND PACKAGE also deletes phased-out package copies. Identify the package by collection (required) and, from the DBRM, package-id and version. Optional location-name binds at a remote server.

1
2
3
4
5
6
DSN SYSTEM(DB2A)
BIND PACKAGE(PAYROLL) MEMBER(PAYCALC) -
  ACTION(REPLACE) OWNER(PAYBIND) QUALIFIER(HR) -
  ISOLATION(CS) RELEASE(COMMIT) VALIDATE(BIND) -
  EXPLAIN(YES) CURRENTDATA(NO) PLANMGMT(EXTENDED)
END

• MEMBER(dbrm) — DBRM from the DBRMLIB concatenation (or LIBRARY option)
• COPY — copy an existing package instead of reading a DBRM
• ACTION(ADD | REPLACE) — add a version or replace
• SQLERROR(NOPACKAGE | CONTINUE | CHECK) — how bind-time SQL errors are handled

The package owner must be authorized to execute the embedded SQL or BIND produces errors (SYSADM and DATAACCESS include that). Adding a package depends on subsystem parameter BINDNV: the BINDADD path needs BINDADD plus CREATE IN or PACKADM; if BINDNV is BIND, PACKADM or BIND on the collection can add a new version of an existing package. REPLACE needs ownership, BIND on the package, PACKADM, or a system authority. EXPLAIN(ONLY) needs the EXPLAIN privilege; SQLERROR(CHECK) needs BIND, BINDAGENT, or EXPLAIN.

Each package contains one DBRM. You do not BIND PACKAGE for a program whose only SQL is SET CURRENT PACKAGESET. Trigger packages are not created with this command.

BIND PLAN

Builds the application plan every program needs in order to allocate Db2 resources at run time. Modern syntax is PKLIST, not a pile of DBRMs.

1
2
3
4
5
6
BIND PLAN(PAYPLAN) -
  PKLIST(PAYROLL.*, COMMON.*) -
  ACTION(REPLACE) RETAIN -
  ISOLATION(CS) RELEASE(COMMIT) -
  OWNER(PAYBIND) QUALIFIER(HR) -
  CACHESIZE(1024)

The MEMBER option is deprecated. If you specify it, Db2 binds those DBRMs into packages and includes them in a package list. Use BIND PACKAGE plus PKLIST unless you cannot. ACTION(ADD) needs BINDADD (or SYSADM / SYSCTRL / system DBADM). ACTION(REPLACE) RETAIN keeps EXECUTE privileges. ENABLE/DISABLE restrict environments (CICS, IMS, BATCH, RRSAF, and so on). Plans are bound locally even when PKLIST names remote packages; bind those packages at the remote location.

REBIND PACKAGE

Rebinds an application package when you make changes that affect the package but have not changed the SQL statements in the program. Examples: CREATE INDEX, RUNSTATS, changing ISOLATION, validating an invalid package. If the SQL changed, use BIND PACKAGE ACTION(REPLACE) with a new DBRM instead.

1
2
3
4
5
6
7
REBIND PACKAGE(PAYROLL.PAYCALC) -
  APREUSE(WARN) APCOMPARE(WARN) -
  PLANMGMT(EXTENDED) EXPLAIN(YES)
 
REBIND PACKAGE(PAYROLL.*) ISOLATION(CS)
 
REBIND PACKAGE(PAYROLL.PAYCALC) SWITCH(PREVIOUS)

You can change any bind option on an ordinary package. Wildcards rebind local packages you are authorized to bind; an asterisk does not apply to remote packages. SWITCH (PREVIOUS | ORIGINAL) makes a PLANMGMT copy current without a full re-optimize — the standard backout after a bad rebind. Autobind, if it runs, replaces only the current copy.

REBIND PLAN

Rebinds an application plan when you change attributes such as the package list. You can change any plan bind options.

1
2
REBIND PLAN(PAYPLAN) PKLIST(PAYROLL.*, COMMON.*, AUDIT.*)
REBIND PLAN(PAYPLAN) NOPKLIST

• PKLIST — replace the previous package list
• Omit PKLIST — keep the previous list
• NOPKLIST — delete the entire package list

Rebinding the plan does not rebind every package on the list. If you need new access paths for the programs, REBIND PACKAGE (possibly with collection.*) as a separate step.

REBIND TRIGGER PACKAGE

Rebinds a package for a basic trigger. Query SYSIBM.SYSTRIGGERS: blank SQLPL means basic. For advanced triggers, use REBIND PACKAGE instead. A trigger package can be explicitly rebound but cannot be explicitly bound with BIND PACKAGE — you create a new trigger package by recreating the trigger.

Use REBIND TRIGGER PACKAGE when you create a new index the trigger SQL should use, or when the trigger package is invalid because a dependent object changed. Success marks the package valid. REBIND TRIGGER PACKAGE(*) affects only basic trigger packages you are authorized to rebind.

1
2
REBIND TRIGGER PACKAGE(PAYROLL.TRIGPAY1) -
  EXPLAIN(YES) ISOLATION(CS) RELEASE(COMMIT)

The documented option subset includes CURRENTDATA, DESCSTAT, EXPLAIN, FLAG, IMMEDWRITE, ISOLATION, RELEASE, SWITCH, CONCURRENTACCESSRESOLUTION, temporal/archive sensitive options, and APPLCOMPAT. You do not get the full BIND PACKAGE option list (for example QUALIFIER on a trigger is not the COBOL-style replace-bind story).

BIND SERVICE

Builds an application package that represents a Db2 native REST service. Db2 records the service in catalog tables (SYSIBM.DSNSERVICE) and saves the prepared package in the directory. The SQL is one static statement (SELECT, INSERT, UPDATE, DELETE, TRUNCATE, CALL, or WITH) supplied on SQLDDNAME or via the createService API.

1
2
3
4
5
BIND SERVICE(PAYROLL) NAME(getEmp) -
  SQLDDNAME(SQLIN) -
  DESCRIPTION('Employee by empno') -
  OWNER(PAYBIND) QUALIFIER(HR) -
  ISOLATION(CS) APPLCOMPAT(V12R1M500)

Service-specific options include NAME, DESCRIPTION, VERSION, SQLDDNAME, and SQLENCODING. Other options match BIND PACKAGE. Authorization follows BIND PACKAGE rules for ADD versus REPLACE, plus the owner must be able to execute the embedded SQL. After bind, the package is executed as a REST service through DDF — not as a normal application CALL. Drop the active service with FREE SERVICE, not FREE PACKAGE on the active copy (inactive PLANMGMT copies can still be freed with FREE PACKAGE and PLANMGMTSCOPE).

A typical COBOL change-management flow

1. Precompile or coprocessor-compile → DBRM + load module (same consistency token)
2. BIND PACKAGE ACTION(REPLACE) or ADD VERSION into the application collection
3. Skip BIND PLAN if PKLIST already has collection.*
4. After RUNSTATS or a new index: REBIND PACKAGE with APREUSE / PLANMGMT
5. If the rebind is bad: REBIND PACKAGE SWITCH(PREVIOUS)
6. When a collection is added to the application: REBIND PLAN PKLIST

Triggers skip steps 1–2: CREATE TRIGGER built the package. REST services skip the COBOL precompile: BIND SERVICE is the bind. BIND QUERY is a seventh cousin for statement-level hints (DSN_USERQUERY_TABLE → SYSQUERY*); it is not required for ordinary COBOL packages.

Explain It Like I'm Five

BIND PACKAGE is cooking a new meal from a recipe card (DBRM) and putting it on a shelf (collection). BIND PLAN is printing the cafeteria ticket that lists shelves. REBIND PACKAGE is recooking the same recipe because you bought a new oven (statistics) or a new pan (index). REBIND PLAN is reprinting the ticket with different shelves. REBIND TRIGGER PACKAGE is recooking the automatic “when someone touches the cookie jar” recipe; you are not allowed to cook that one from a COBOL card. BIND SERVICE is wrapping one meal so a phone app can order it over the internet instead of sitting in the dining room.

Exercises

1. Write BIND PACKAGE and BIND PLAN for program ORDADD, collection APP, plan ORDPLAN, qualifier ORD.
2. A new index was created and SQL did not change. Which command do you run, and which PLANMGMT/APREUSE options would you add for a cautious production shop?
3. How do you tell REBIND TRIGGER PACKAGE from REBIND PACKAGE using SYSTRIGGERS?
4. Why is FREE SERVICE required instead of FREE PACKAGE for an active REST service?
5. Convert a BIND PLAN MEMBER(A,B) job into BIND PACKAGE plus BIND PLAN PKLIST statements.