Automatic binds in coexistence
Changes to package structures that are introduced in DB2® 10 are not available to members of the group that have not migrated. You must plan accordingly when developing your migration plan.
It is best to prevent packages that are bound or rebound on DB2 10 from running on members that have not yet been migrated, for the following reasons:
- To prevent the automatic rebinds that occur when plans or packages that are bound on Version 10 run on Version 8 or Version 9.
- To prevent automatic remigration rebinds, which might occur repeatedly when a Version 10-bound plan or package that was automatically rebound on Version 8 or Version 9 is later run again on Version 10.
The
migration process binds new packages in DB2 10, including packages for DB2-supplied stored procedures,
user defined functions, and tools such as SPUFI and the DB2
REXX language support. Data sharing members in the DB2 10 load and execute those programs from the
DB2 10 SDSNLOAD library. Data sharing members
on DB2 9 continue to load this packages from
the SNDSNLOAD library for DB2 9.
If you must rebind some of your application packages in Version 10 while coexistence with DB2 Version 8 or DB2 9 continues, you must consider how to handle the resulting binds and automatic rebinds while the different releases coexist. In most cases, the recommended approach is to avoid repeated remigration rebinds by setting the value of the ABIND subsystem parameter to COEXIST.