Mixed releases in a DB2 data sharing group

A DB2® data sharing group can remain available while you migrate members of the group from DB2 9 to DB2 10 release.

However, planning the migration for periods of low activity in the group is recommended because, due to locks that are obtained by the catalog migration utility (CATMAINT), parts of the DB2 catalog are unavailable during the migration of the first member. The parts that are unavailable vary from release to release, depending on what catalog parts require modification.

The purpose of coexistence is to allow applications to continue to access DB2 data while you migrate the members of the data sharing group. However, you must weigh the benefit of continuous availability against the operational costs of running in coexistence mode: new functions are not available, and there are some system management issues to consider.

If you do not require continuous availability, consider shutting down the group during the migration to avoid the coexistence environment. If must run in coexistence, plan to migrate the members in as short a time as possible so that you can minimize the operational complexity.

Special considerations for WLM-managed stored procedures in coexistence
The WLM-managed stored procedure address space (WLM-SPAS) that processes a stored procedure or UDF program always connects to the DB2 member that processes the SQL call request. Therefore, the DB2 code that is executed in the WLM-SPAS must match the DB2 release of the DBM1 address space, or an error occurs.
Determining the release of a data sharing group in coexistence
When the first data sharing member starts DB2 10, the catalog is considered to be at that level, even though not all members of the group have migrated. This means that the catalog level for the group is DB2 10.
Determining the function level of an IRLM group in coexistence
IRLM communicates coexistence information by using function levels. A function level is an ever-increasing number that each IRLM can use to tell other IRLMs in the group what level of function it supports.
Call attachment and TSO attachment in coexistence
While operating in a coexistence environment, you can attach to either DB2 release with your existing TSO logon procedures or with JCL.
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.
Recommendations for BIND in coexistence
If DSN is at DB2 10 and the member that is named in the DSN command is at Version 8 or DB2 9, using certain bind options causes a BIND or REBIND subcommand to be rejected.
Recommendations for utilities in coexistence
Until all members of the data sharing group are running DB2 10, avoid using any of the new utility functions that are available in DB2 10. However, as long as you use utility options that are supported in Version 8 or Version 9, utilities can attach to either a Version 8 or Version 9 member.
Load module names for running purchased utilities in coexistence
Each utility that you purchase has a separate load module that is associated with one of 20 load modules.
Recommendation for group restart in coexistence
If a group restart is necessary while the data sharing group is running in a coexistence environment, issue the START command only for DB2 10 members.
Recommendation for SPUFI in coexistence
When you migrate the first member of the data sharing group to DB2 10, you run job DSNTIJSG, which binds the SPUFI packages in DB2 10.

Parent topic: Installing, migrating, and enabling DB2 data sharing

Related reference:

CATMAINT