Release coexistence in Db2 data sharing

In release coexistence, applications can 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. Most new capabilities and enhancements in Db2 12 remain unavailable during coexistence, and additional system management considerations apply.

Start of change Db2 12 supports coexistence with Db2 11 members as long as every member remains at function level 100. End of change Release coexistence begins when you migrate the first data sharing member to Db2 12. You must successfully migrate the first data sharing member to Db2 12 before attempting to migrate the other data sharing members.

Important: Apply the for fallback SPE (APAR PI33871) and stop and restart Db2 11 for every subsystem or data sharing member that you plan to migrate to Db2 12. For data sharing, every member must be started in Db2 11 after the fallback SPE is applied. Inactive members that never started with the fallback SPE applied in Db2 11 cannot start in Db2 12 or Db2 11 after migration to Db2 12 and activation of function level 500 on any other member. See Required maintenance for Db2 12 installation or migration.

For maximum availability, you can migrate the members to Db2 12 one member at a time. Start of change When developing your migration plan, remember that most new functions that are introduced in Db2 12 are not available to any members of the group until all members are migrated to Db2 12 and is activated. End of change

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

Plan migrations for periods of low activity because of the locks used by the catalog migration utility (CATMAINT). These locks make parts of the Db2 catalog are unavailable during migration of the first member. The locks used varies from release to release, depending on the catalog parts that require modification.

Coexistence considerations are similar to those that you need to understand for the fallback environment. For example, objects that are frozen in fallback are generally not accessible from a Db2 11 member.

Activation of Db2 12 function levels

In Db2 12, new function is activated when you successfully issue the ACTIVATE command on any single member of the data sharing group.

Tip:

Begin general-use programming interface information.

You can determine the catalog level and function level for a Db2 subsystem or data sharing group, and the code levels of individual subsystems or members, by issuing DISPLAY GROUP commands. For more information, see Determining the Db2 code level, catalog level, and function level End general-use programming interface information.

End general-use programming interface information.

Before attempting this process, confirm that all members are running Db2 12. The ACTIVATE command is successful only if all active members are running Db2 12.

Important: Do not issue the ACTIVATE command or run job DSNTIJAF for activation of Db2 12 until you are certain that the subsystem or data sharing group can proceed on Db2 12, without the possibility of falling back to or coexistence with Db2 11. In data sharing, the ACTIVATE command has group scope. Fallback and coexistence become impossible with the successful activation of function level 500 or higher.

TSO, CAF, and RRSAF logon procedures

You can attach to either release of Db2 with your existing TSO, CAF, or RRSAF logon procedures without changing the load libraries for your applications. After you migrate completely to the latest level of Db2, you must update those procedures and jobs to point to the latest level of Db2 load libraries. If you forget to update those procedures and jobs before migrating to any release subsequent to Db2 12, those procedures and jobs can no longer work in that subsequent release.