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. Start of change FL 502 However, if statement-level invalidation is enabled for a package, Db2 can mark the package invalid at a statement level by setting VALID='S' in the SYPACKAGE catalog table only. End of change

If an automatic rebind fails, Db2 marks a package as inoperative in the OPERATIVE column of SYSIBM.SYSPLAN and SYSIBM.SYSPACKAGE catalog tables. FL 504 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 (Db2 13 uses the same behavior is used for both settings.). 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.
The automatic rebind value for APREUSE is WARN, and the automatic rebind value for APREUSESOURCE is CURRENT.
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.

Autobind phase-in for packages with statement-level invalidation

FL 504 Db2 uses autobind phase-in for packages that are marked with statement-level invalidation. Packages with invalid statements can be allocated, and valid statements can execute without waiting for the rebind to complete. However, invalid statements must go through incremental bind before they execute. For more information, see Autobind phase-in for packages with statement-level invalidation and Enabling autobind phase-in for packages invalidated at the statement level.

When automatic binds fail

When 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).

Start of change FL 504 For autobind phase-in, the current package copy is marked in rebind-advisory status by setting the OPERATIVE='R' in the SYSIBM.SYPACKAGE catalog table. For other autobinds, the current copy is marked as inoperative with OPERATIVE='N' in the SYSIBM.SYSPLAN and SYSIBM.SYSPACKAGE catalog tables. 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.