Beginning with your migration to Db2 12 for z/OS, you will be embarking on a new journey called continuous delivery. This new way of delivering new features into IBM program products such as Db2 for z/OS will change the migration process and the way you deal with applications going forward. Whether you are a developer, database administrator or systems programmer, there are things you need to know about this change.
The Migration Process (Systems Programmers)
The last several releases involved a multi-phased migration. For example, when migrating from Db2 10 to Db2 11, there were three distinct phases of this migration involving two places where the Db2 catalog undergoes structural change (CATMAINT). This sometimes lengthened the process of the migration and the work was spread out over several months.
The Db2 12 migration will happen in a single phase (only one initial CATMAINT) followed by the activation of new function levels to enable new functionality. These function levels are named according to their version, release and a new modification identifier. For example, when you first migrate to Db2 12 you will be at level V12R1M100.
Function level V12R1M100 will serve a similar purpose to Conversion Mode (CM) in past releases. Db2 12 enhancements related to optimization and virtual storage will be available and enhancements related to SQL will be unavailable until you reach a higher function level. Function level V12R1M500 is the first function level that enables SQL functionality for Db2 12 and it may be activated by a simple command:
In order to activate future function levels, there are a few considerations. Some function levels require catalog changes. When this is the case, there will be a CATMAINT required before that function level may be activated. Each function level will also have an APAR that will help you coordinate maintenance to support the new function level. Each new function level will identify the APAR and the corresponding catalog level necessary to activate that function level.
A catalog table SYSIBM.SYSLEVELUPDATES tracks events that affect function levels. Examples include maintenance updates, execution of CATMAINT and ACTIVATE commands.
For a list of currently supported function levels and the details of the required maintenance visit IBM’s website below. Details of any incompatibilities are also documented.
https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/wnew/src/tpc/db2z_db2functionlevels.html
As of this writing the following function levels are available:
- V12R1M100
- V12R1M500
- V12R1M501
- V12R1M502
- V12R1M503
Managing Applications
Database Administrators and Developers also need to plan for continuous delivery. This will involve a deep understanding of something delivered in Db2 11, namely the APPLCOMPAT bind parameter.
This bind parameter allows you to determine how you want your applications to behave. For instance, you can be running Db2 12 at function level V12R1M502 but have a set of programs that is not yet ready for Db2 12 behavior. If this is the case, you can bind those programs using APPLCOMAPT(V11R1). There is an APPLCOMPAT subsystem parameter that controls the default as well as a special register called CURRENT APPLICATION COMPATIBILITY that may be used by dynamic SQL to override the level of the package.
Once Db2 12 is implemented this parameter will also be used to determine the behavior of applications across the various function levels. The full function level should be specified in the APPLCOMPAT option of the bind. The default will be taken from the APPLCOMPAT system parameter. Since it’s unlikely that most applications will specify this option on a bind, it’s important to chose the value for the system parameter carefully.
In order for an application to use new features of Db2 12, the system must have activated function level V12R1M500 or above and be bound with APPLCOMAT(V12R1M500) or above. When a bind changes the value for APPLCOMPAT to a higher level, more SQL functionality becomes available BUT the program must also be prepared for any documented changes in behavior associated with the higher level. This allows migration and activation of new function levels to proceed somewhat independently from each application’s readiness to accept new behavior. Note: The behavior described does not include performance. This discussion centers on applications producing a predictable set of results.
Fallback Considerations
After activating a new function level, you may fall back to a previous level by simply running the appropriate ACTIVATE command. When this is done there will be an * placed by the current level (e.g. V12R1M100*). It is possible that packages were bound at a higher level and these will continue to run and be supported. Once V12R1M500 (or above) has been activated it is no longer possible to fall back to Db2 11.
Conclusion
This new approach is going to change the way we do maintenance and manage applications. This article is not intended to be an exhaustive discussion. Feel free to comment below with your own thoughts and questions!
David Simpson
Themis Training
dsimpson@themisinc.com