Migrating your Db2 subsystem to Db2 12

The migration process for Db2 12 has a single phase. However, most new capabilities and enhancements in Db2 12 remain unavailable until you issue an ACTIVATE command to activate function level 500 or higher.

Before you begin

Before you begin migration to Db2 12, read all information in Preparing your system to install or migrate to Db2 12.

Attention: If you do not follow the documented procedures, unpredictable results might occur after migration to Db2 12.

Ensure that your Db2 11 subsystem is running in new-function mode and is at the proper service level. For more information about identifying required service, see Required maintenance for Db2 12 installation or migration.

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.

About this task

When you start Db2, the code level of the starting Db2 is compared to the code level that is required by the current Db2 catalog. If the starting Db2 has a code-level mismatch with the catalog, Db2 does not start and a message is issued.

Refer to the Db2 Program Directory for keyword specifications that are used for Preventive Service Planning (PSP) and for information about the service levels of any coupling facilities. You can use the z/OS® DISPLAY CF command to display the service level of coupling facilities. Check Information/Access or the ServiceLink facility of IBMLink for PSP information before you migrate. Or, to help you identify required service, you can instead use enhanced HOLDDATA and fix categories (FIXCATs), which provide a simplified, automated method of identifying and applying missing PTFs that are required for installation or migration. Also, check monthly for current information about Db2.

Restriction: After migration to Db2 12, the administrative task scheduler is disabled until you run job DSNTIJRT.

Procedure

To migrate a Db2 for z/OS subsystem to Db2 12:

Estimate storage needs for your Db2 12 environment. For more information, see Storage requirements for Db2 for z/OS.
Determine the new capabilities that you want use in Db2 12, and make plans for other changes in the new release. For more information, see:
- What's new in Db2 12
- Changes to plan for in Db2 12
If you are using distributed data, install TCP⁄IP, VTAM, or both. For more information, see Connecting distributed database systems .
If you plan to use data sharing, set up a Parallel Sysplex®. For more information, see Parallel Sysplex requirements for Db2 data sharing.
Use SMP/E to load the Db2 12 libraries. For more information, see Making the Db2 product code available.

Remember: If you copy Db2 library data sets from one system another, such as for installing a related test or production subsystem, ensure that you copy all of the Db2 library data sets to the same location. For example, if you copy the SDNSLOAD data set from one system to another but omit the DBRMLIB data set, the resulting mismatch can cause job DSNTIJRT to fail with SQLCODE -812.

If you plan to use the callable SQL interface of Db2, see Configuring Db2 ODBC and running sample applications for the additional installation jobs that you need to run. If you plan to use Db2 for z/OS Java™ Edition, you must run more installation jobs. For more information, see Installing the IBM® Data Server Driver for JDBC and SQLJ.
Install needed service on Db2 11. For information about the required service to apply, see the Program Directory.

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.
Check for release incompatibilities, and make the necessary changes in your applications. For more information, see Make adjustments for incompatible changes in Db2 12.
Generate tailored JCL jobs for migrating to Db2 12. You can use the Db2 installation CLIST. For more information, see Generating tailored installation, migration, or function level activation jobs by running the Db2 installation CLIST in interactive mode.
Complete the following migration tasks:
When you are ready to use new capabilities in Db2 12, activate new function as described in Activating Db2 12 new function at migration.
Install, configure, and verify Db2-supplied routines that depend on Db2 12 function levels, as described in Installing and configuring Db2-supplied routines that use new function: DSNTIJRT.
Verify the successful migration to Db2 12, as described in Verifying successful migration to Db2 12.
Enable more capabilities in your Db2 environment. For more information, see Configuring additional capabilities for Db2 for z/OS.

What to do next

You might want to activate new capabilities that are introduced by higher Db2 12 function levels. For more information about continuous delivery and function levels in Db2 12, see the following topics:

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.