About Rebinding Components

Rebind executes only the program bind portion of a stage procedure to rebuild a composite load module composed of a statically linked main program and subroutines. Rebind obtains object and load modules from a SYSLIB concatenation of staging, promotion, and baseline libraries. If one exists, a link edit control member (with the same name as the component being rebound) is obtained from either a staging or baseline library.

An important secondary benefit of rebind is that component history and prior baseline versions reflect actual changes, not just multiple copies of the same component. Prior versions in baseline libraries are limited, and if you checkout, stage, and install the same component with no changes, real changes are lost from the oldest versions in baseline libraries.

You can initiate rebind from your change package to add like-load components to the package. Rebind may also be invoked by the auto resolve feature of package audit to fix some SYNCH errors.

In order to ensure that rebinds rebuild composite load modules correctly it is important to separate constituent NCAL subroutines from the final composite executables by using different library types for each (object code subroutines are forced to have a different library type owing to their differing DCB requirements).

Then, when rebuilding a composite executable, you can rebind from the top level NCAL (or object code) component library type to the composite executable library type. This will not only ensure that manual rebinds pick up the latest versions of subroutines (either via automatic library call or via link edit control card direction or a combination of both) but it will also allow audit autoresolve to correctly rebuild your executables should they be found to be out of synch.

Note that rebinding a fully resolved composite executable achieves nothing. Unless directed by REPLACE link edit control cards the program binder will not disturb a fully resolved load module.