Standard bind automation concentrates on the target environment (e.g. promotion or install target).

With the dynamism of Db2 package location this is generally good enough. Db2 is very good at finding an appropriate package with which to execute your Db2 executable. There are situations where a Db2 component change in one environment invalidates the execution of that component in a different environment.

For example, when making use of logical subsystems to separate different testing environments within the same physical Db2 subsystem, insertion of a change further up the lifecycle (e.g. a hotfix) can invalidate the search for a suitable package lower down the lifecycle.

A new Db2 option facility is available at ZMF 8.3 to allow secondary binding to be automated, i.e. given that the target logical subsystem is ‘this’ then we will also require an automated bind (using relevant clause value templating) at ‘that’ logical subsystem. A single primary target logical subsystem can be related to more than one secondary logical subsystems.

For details see the ZMF 8.3 Db2 option GSG (doc is available here)

Chapter 2 (Configuring the Db2 option) – Define Secondary Bind requirements   

Chapter 6 (CMNDB2PL – Bind utility) – Secondary Binding

Appendix B (ISPF Tables and Variables) – CMNDB22N secondary bind table