Automatic rebinds

Automatic rebinds (sometimes called autobinds) occur when an authorized user runs a package or plan and the runtime structures in the plan or package cannot be used. This situation usually results from changes to the attributes of the data on which the package or plan depends, or changes to the environment in which the package or plan runs.

For a list of actions that might cause Db2 to mark packages invalid, see Changes that invalidate packages.

In most cases, Db2 marks a package that must be automatically rebound as invalid by setting VALID='N' in the SYSIBM.SYSPLAN and SYSIBM.SYSPACKAGE catalog tables.

If an automatic rebind fails, Db2 marks a package as inoperative in the OPERATIVE column of SYSIBM.SYSPLAN and SYSIBM.SYSPACKAGE catalog tables. However, if autobind phase-in fails for a package that is invalidated at the statement level, OPERATIVE='R' is used in the SYSPACKAGE table only.

Controls for automatic binds

Db2 uses automatic binds only when the ABIND subsystem parameter is set to YES or COEXIST. If ABIND is set to NO when an invalid package runs, Db2 returns an error. For details, see AUTO BIND field (ABIND subsystem parameter).

You can also use resource limit tables to control automatic binds. For details, see Restricting bind operations.

Bind options for automatic binds

In general, Db2 uses the same bind options from the most recent bind process for automatic binds. The exceptions are:

  • If an option is no longer supported, the automatic rebind option process substitutes a supported option.
  • If an option does not have an existing value, the default bind option is used.
  • The automatic rebind value for APCOMPARE is NONE.
  • Start of changeThe automatic rebind value for APREUSE is WARN, and the automatic rebind value for APREUSESOURCE is CURRENT.End of change
  • If there is no existing value for the APPLCOMPAT bind option, the APPLCOMPAT subsystem parameter is used.
  • If there is no existing value for the DESCSTAT bind option, the DESCSTAT subsystem parameter is used.

Automatic binds with package copies

If a package has previous or original copies as a result of rebinding with the PLANMGMT(BASIC) or PLANMGMT(EXTENDED) options or having the PLANMGMT subsystem parameter set to BASIC or EXTENDED, those copies are not affected by automatic rebind. Automatic rebind replaces only the current copy.

A situation can occur in which automatic rebind causes the previous or original copy to be at a newer Db2 version than the current copy. Suppose that copy A is the current copy, and copy B is the previous copy. Copy A is at a previous and supported version for Db2 packages, but copy B is at an older Db2 version than the minimum supported version. When you switch the packages so that copy B becomes the current copy, and run copy B, Db2 automatically rebinds copy B. Now, copy B is at a newer Db2 version than copy A.

When automatic binds fail

Start of changeWhen an automatic bind fails, Db2 issues message DSNT500I to the console with reason ‘00E30305’x, resource type '804'x, and resource name collection.package.(version).End of change

If EXPLAIN(YES) was specified for the previous rebind operation, the ABEXP subsystem parameter controls whether Db2 captures EXPLAIN information during automatic rebinds. For details, see EXPLAIN PROCESSING field (ABEXP subsystem parameter). Automatic rebinds fail for most EXPLAIN errors.

If an automatic bind occurs while running in ACCESS(MAINT) mode the automatic bind is run under the authorization id of SYSOPR. If SYSOPR is not defined as an installation SYSOPR the automatic bind fails.