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 13 remain unavailable during coexistence, and additional system management considerations apply.
Db2 13 supports coexistence with Db2 12 members as long as every member remains at function level 100. Release coexistence begins when you migrate the first data sharing member to Db2 13. You must successfully migrate the first data sharing member to Db2 13 before attempting to migrate the other data sharing members.
Important: Inactive members that never started in
Db2 12 with the fallback SPE (
APAR PH37108) applied cannot start after the first data sharing member is migrated to
Db2 13 at function level 100.
For maximum availability, you can migrate the members to Db2 13 one member at a time. When developing your migration plan, remember that most new functions that are introduced in Db2 13 are not available to any members of the group until all members are migrated to Db2 13 and is activated.
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 12 member.
Removed subsystem parameters in Db2 13 (function level 100 and higher)
The following table lists subsystem parameters that are removed from this version of Db2 for z/OS®. Refer to the information for the earlier version for detailed descriptions of the removed subsystem parameters.
Important: For best results, check the setting used in your Db2 12 environment, especially in data sharing environments. If the current setting does not match the setting listed in the following table, evaluate whether any other changes are needed to accept the new-behavior settings, before migrating to Db2 13.
| Subsystem parameter |
Setting used in Db2 13 |
Description in earlier releases |
Incompatible change? |
| AUTHCACH |
4K |
Specifies the size (in bytes per plan) of the authorization cache that is to be used if no CACHESIZE is specified on the BIND PLAN subcommand. |
No |
| DDF_COMPATIBILITY |
NULL |
Controls certain characteristics of a connection between a client application and a Db2 for z/OS data server.
|
Yes |
| DSVCI |
YES |
Controls whether Db2-managed data sets that are created by CREATE TABLESPACE or CREATE INDEX statements are to have variable VSAM control intervals. |
No |
| EXTRAREQ |
100 |
Limits the number of extra DRDA query blocks that Db2 can request from a remote DRDA server. |
No |
| EXTRSRV |
100 |
Limits the number of extra DRDA query blocks that Db2 can return to a DRDA client |
No |
| HONOR_KEEPDICTIONARY |
NO |
Specifies whether Db2 honors the LOAD and REORG parameter KEEPDICTIONARY when tables are converted between basic row format and reordered row format.
|
No |
| IMMEDWRI |
NO |
Determines when updates to group buffer pool-dependent buffers are to be written to the coupling facility. |
No |
| IX_TB_PART_CONV_EXCLUDE |
YES |
Specifies whether to exclude trailing columns from the table-controlled partitioning keys when table spaces are converted from index-controlled partitioning to table-controlled partitioning. |
No |
| MAXARCH |
10000 |
Controls the maximum number of archive log volumes that are to be recorded in the BSDS.
|
No |
| MAXTYPE1 |
0 |
Determines the number of inactive DBATs that Db2 is to allow. |
No |
| OPT1ROWBLOCKSORT |
DISABLE |
Specifies whether Db2 explicitly blocks sort operations when the OPTIMIZE FOR 1 ROW clause is specified on a query. |
No |
| PARA_EFF |
50 |
Controls the efficiency that Db2 assumes for parallelism when Db2 chooses an access path. |
No |
| PLANMGMTSCOPE |
STATIC |
Specifies the types of SQL statements for applying the PLANMGMT subsystem parameter setting. |
No |
| REALSTORAGE_MANAGEMENT |
AUTO 1 |
Specifies whether Db2 should manage real storage consumption. Important: Keep your current setting in Db2 12. See note 1.)
|
No |
| RESYNC |
2 |
Specifies the time interval, in minutes, between resynchronization periods. |
No |
| SUBQ_MIDX |
ENABLE |
Specifies whether to enable or disable multiple index access on some non-Boolean uncorrelated subquery predicates. |
No |
| TRACSTR |
NO |
Specifies whether the global trace starts automatically when Db2 starts. |
No |
Notes:
- If you currently use a different setting, do not change the REALSTORAGE_MANAGEMENT setting to AUTO in Db2 12.
Db2 13 uses enhanced automatic behavior for real storage management, which differs from the thread-based discard processing used with REALSTORAGE_MANAGEMENT=AUTO in Db2 12 or earlier.
Db2 13 manages real storage discard processing at the system level to avoid z/OS RSM serialization from discard requests.
Activation of Db2 13 function levels
In Db2 13, new function is activated when you successfully issue the ACTIVATE command on any single member of the data sharing group.
Before attempting this process, confirm that all members are running Db2 13. The ACTIVATE command is successful only if all active members are running Db2 13.
Important: Do not issue the ACTIVATE command or run job DSNTIJAF for activation of Db2 13 until you are certain that the subsystem or data sharing group can proceed on Db2 13, without the possibility of falling back to or coexistence with Db2 12. In data sharing, the ACTIVATE command has group scope. Fallback and coexistence become impossible with the successful activation of function level 500 or higher.
Important: Inactive members that never started in
Db2 12 with the fallback SPE (
APAR PH37108) applied cannot start after the first data sharing member is migrated to
Db2 13 at function level 100.
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 13, those procedures and jobs can no longer work in that subsequent release.
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