Db2 for z/OS and its ecosystem

By John Lyle and Paul McWilliams. 

IBM recently announced the upcoming general availability (GA) of Db2 13 for z/OS on May 31, 2022. Are you ready for migration to Db2 13? 

Db2 12 introduced the concepts of single-phase migration, continuous delivery, and function levels. Db2 13 evolves these concepts to enable truly online migrations without application outages, especially in Db2 data sharing environments. The Db2 13 migration process enables you to adopt new features that benefit your business faster than ever. 

You can expect to follow the same basic steps for generating and running migration jobs as you did for a migration to Db2 12. The main differences to expect in Db2 13 relate to the timing of the catalog updates and the activation of new capabilities that depend on catalog changes. Here’s an overview of some of the key differences from Db2 12 to help you get started. 

Preparing Db2 12 for migration to Db2 13 

Before you can migrate a Db2 12 subsystem to Db2 13, you must first complete the following activities: 

• Activate function level V12R1M510 (FL 510). FL 510 doesn’t include any new capabilities or functionality in Db2 12. Instead, FL 510 ensures that every Db2 12 subsystem is at a common starting place for a migration to Db2 13: the last Db2 12 function level activated (FL 510) and the Db2 catalog is at the final Db2 12 level (V12R1M509), with all Db2 12 function levels activated and the Db2 catalog at catalog level V12R1M509. It also checks for packages that need to be rebound. For more about activating FL 510 in Db2 12, see our previous blog entry. 
• Apply the PTF for the fallback SPE APAR (PH37108) on every Db2 subsystem or data sharing member and stop and restart Db2 12 after it is applied.  

Catalog levels for Db2 13 migration 

Unlike Db2 12, which started at catalog level V12R1M500 in FL 100, a migrated Db2 13 subsystem starts at catalog level V13R1M100, which is structurally identical to catalog level V12R1M509. You still run CATMAINT as part of the migration process in Db2 13, but the first structural changes to the Db2 catalog for Db2 13 occur later, when Db2 13 is at FL 500 and you update to catalog level to V13R1M501 (CL 501).  

Delaying the structural changes simplifies the migration process in several ways:  

• Removes any need for Db2 12 to be aware of the catalog changes in Db2 13, greatly simplifying the fallback SPE APAR. 
• Eliminates the invalidation of packages that depend on the catalog, and the resulting automatic binds that might occur, especially the “ping-pong” automatic binds that could occur during release coexistence and fallback. 
• Reduces contention that might occur between applications and utilities that are running concurrently with the CATMAINT operation. 

You might wonder why the Db2 13 migration process still includes a step to run CATMAINT, even though the catalog updates for Db2 13 are delayed until CL 501. The reason is so that you can decide when the migration completes and Db2 13 is available for use. The initial CATMAINT process also sets internal information that indicates that the Db2 13 is at CL 100 and FL 100. 

Db2 13 includes function level FL 501 at GA 

At GA, Db2 13 includes three function levels for migrating systems, instead of the two used in Db2 12. The inclusion of function level 501 at GA simplifies online migration, especially in data sharing, by delaying the Db2 13 catalog updates until release coexistence with Db2 12 and fallback are no longer possible.

V13R1M100 (FL 100)

Migrated Db2 subsystems start at this function level. As with FL 100 in Db2 12, many Db2 13 optimizations and enhancements that are transparent to your applications start working immediately, although some require that you rebind packages or refresh the dynamic statement cache.  

• Most new application capabilities are unavailable until you activate FL 500 or higher.  
• Fallback remains supported for Db2 13 subsystems at FL 100, and release coexistence with Db2 12 remains possible in data sharing.  
• As mentioned above, the Db2 catalog is at CL 100 for FL 100. 

V13R1M500 (FL 500)  

Activating FL 500 enables many of new capabilities in Db2 13. As with FL 500 in Db2 12, the following rules apply for activating FL 500 in Db2 13: 

• You cannot activate FL 500 if any data sharing members are still active on Db2 12 
• Activating FL 500 prevents any fallback to Db2 12. 
• Activating FL 500 prevents future release coexistence with Db2 12. 

 You can activate FL 100* after activating FL 500 or higher, but doing that does not let you fallback or return to release coexistence in data sharing. This works the same as it did in Db2 12.  

Unlike Db2 12, new capabilities that depend on Db2 catalog changes remain unavailable at FL 500, and no catalog update is required for activation of this function level. At FL 500, all GA-level new function in Db2 13 that does not require catalog updates is available for use. 

V13R1M501 (FL 501)  

Whereas a newly installed Db2 12 system starts at FL 500 by default, a newly installed Db2 13 system starts at FL 501. For migration, activating FL 501 represents the first opportunity to use any new capabilities of Db2 13 that require catalog changes. Before you can activate FL 501, you must first update the Db2 catalog to CL 501.  

Db2 13 migration process overview 

At a very high level, the Db2 13 migration process has these basic steps: 

1. In Db2 12, update the Db2 catalog to catalog level V12R1M509 and activate Function Level V12R1M510.
2. In Db2 12, apply the fallback SPE (APAR PH37108) and stop and start the Db2 subsystem. In data sharing, you must do this on every member.
3. Migrate Db2 12 to function level V13R1M100. You can generate the jobs by running the installation CLIST in MIGRATE mode. The TARGET FUNCTION LEVEL field on DSNTIP00 is forced to V13R1M100. That catalog level is V13R1M100, which has no structural changes from catalog level V12R1M509. The steps are very similar to the migration process from Db2 12. Fallback to Db2 12 and release coexistence with Db2 12 in data sharing remain possible from FL 100.
4. When you are certain that fallback and release coexistence with Db2 12 are no longer required, activate function level V13R1M500 or higher. If you are not ready for the catalog changes in Db2 13 but you want to start using some new capabilities, you can activate function level 500 to get many of the new application capabilities in Db2 13.
5. When you are ready to update the catalog with changes for Db2 13, and activate function level 501, and then generate the migration jobs by running the installation CLIST in MIGRATE mode. Specify CURRENT FUNCTION LEVEL V13R1M100 and TARGET FUNCTION LEVEL V13R1M501. 
6. Run the generated DSNTIJA0 job to issue ACTIVATE FUNCTION LEVEL V13RM500.
7. Run the generated DSNTIJTC job or CATMAINT with UPDATE LEVEL V13R1M501.
8. Run the generated DSNTIJAF job for ACTIVATE FUNCTION LEVEL V13R1M501. 

Application compatibility levels in Db2 13 

As in earlier releases, most new application capabilities in Db2 13 are also controlled by the application compatibility (APPLCOMPAT) level of the applications. So, your applications can continue to run with the behavior of earlier releases or function levels until you are ready for them to start using new function. Db2 13 fully supports applications that run V10R1 application compatibility or later, at all available function levels.   

Also, if you return to a lower (*) function level, remember that the APPLCOMPAT level of specific applications is the main control over the use of the new function from the higher function level. To really stop applications from using new function from a higher function level, you must also reduce the APPLCOMPAT level of the applications. 

Stay tuned for more about Db2 13 

Stay tuned to future entries in this blog for more details about the specific new capabilities coming in each Db2 13 function level.