Function levels and related levels in Db2 12
Enhancements to Db2 are enabled for use when you activate function levels.
Each function level corresponds to a single APAR that enables a set of enhancements that were previously delivered in the service stream. A particular function level might enable one or several enhancements.
Before you can activate a function level, your data sharing group or Db2 subsystem must be at the appropriate catalog level, and every member must be at the minimum required code level.
In most cases, you can activate a higher function level without separately activating each lower function level above the currently activated function level. However, activating a higher function level also activates all capabilities that are introduced by all function levels lower than the one being activated.
Function level identifiers
In most cases, code levels, catalog levels, function levels, and application compatibility levels are specified in commands and message output by nine-character strings that correspond to the Db2 version, release, and modification value. However, descriptions of function levels in documentation often refer only to the modification part of the values.
The format is
VvvRrMmmm, where vv is the version, r is the release, and mmm is the modification level. For example,
V12R1M510 identifies function level 510. For a list of all available function levels in Db2 12, see Db2 12 function levels.
The code level of a Db2 subsystem or data sharing member indicates that the necessary APAR and any prerequisite new function code, defect fixes, and other service items for a corresponding function level are applied. Because new function levels are delivered in the same service stream as other maintenance items, the code level is likely to increase as you routinely apply maintenance to a subsystem or member. If you proactively apply maintenance, you can expect the code level to be higher than the catalog level or function level as you prepare to adopt of new Db2 capabilities.
If you remove maintenance items that support or are otherwise related to a code level, Db2 reverts to a lower code level. However, you cannot start Db2 at a lower code level after tailoring the catalog to a higher catalog level or activating a higher function level. For this reason, it is essential that you tailor the catalog at a higher catalog level or activate a function level only after you are certain that Db2 can continue to run at the corresponding code level.
In a data sharing group, each member can be at a different code level. However a function level is always activated at the group level. That is, if any data sharing member is not at the minimum required code level when you attempt to activate a function level, the ACTIVATE command fails. The DSNU757I message output indicates the current and required code levels.
Each code level is identified by the same identifier as the function level that it enables. The format is
VvvRrMmmm, where vv is the version, r is the release, and mmm is the modification level.
In DISPLAY GROUP command output, the DB2 LVL column indicates the code level of each data sharing member or subsystem in a six-character string that contains the Db2 version, release, and modification values. The format is vvrmmm, where vv is the version, r is the release, and mm is the modification level.
A catalog level of a data sharing group or subsystem indicates that a particular CATMAINT utility UPDATE LEVEL job was run on the Db2 catalog, and the data sharing group or subsystem is ready for the activation of certain function levels.
Each function level requires a specific catalog level. However, not every function level requires a new catalog level. If the catalog is not at the minimum required level when you attempt to activate a function level, the ACTIVATE command fails. The message output indicates the current and required catalog levels.
The catalog level is updated when you submit a CATMAINT utility job by tailoring and running the DSNTIJTC sample job. You can use a single CATMAINT job that specifies the target function level. If the target function level requires multiple catalog level updates, the CATMAINT job processes each update in sequential order. If a later update in the sequence fails, the previous successful updates do not roll back, and the catalog level remains at the highest level reached. If that occurs, you can correct the reason for the failure and resubmit the same CATMAINT job.
Whereas different data sharing members can be at different code levels in a data sharing group, a data sharing group has a single catalog level.
Each catalog level is identified by the same identifier as the lowest function level that requires it. The format is
VvvRrMmmm, where vv is the version, r is the release, and mmm is the modification level. For example function level 510 requires catalog level V12R1M509.
An exception is function level 100, which requires catalog level V12R1M500. However, catalog level V12R1M500 is the result when you tailor the catalog for migration to Db2 12, as described in Installation step 16: Tailor the Db2 catalog: DSNTIJTC.
To find when the catalog level changed, you can check the SYSIBM.SYSLEVELUPDATES catalog table or check for message DSNG014I on the console.
A function level enables a particular set of new Db2 capabilities and enhancements that were previously delivered in the single continuous stream of Db2 code. It includes code that supports new capabilities, defect fixes, and preventive service items. Before you can use the new capabilities of a function level, you must activate the function level, or a higher function level. Activation of a function level implies activation of the capabilities that are introduced by all lower function levels.
In data sharing groups, function levels are activated at the group level. That is, if any data sharing member is not at the minimum required code level when you attempt to activate a function level, the ACTIVATE command fails. The DSNU757I message output indicates the current and required code levels.
To find when the function level changed, you can check the SYSIBM.SYSLEVELUPDATES catalog table or check for message DSNG014I on the console.
Before applications can use new SQL capabilities that a function level introduces, the applications must run at the equivalent application compatibility level or higher.
Application compatibility levels
You can use the application compatibility level of applications, and objects such as routines or triggers, to control the adoption and use of new and changed SQL capabilities that are introduced in function levels. Generally, applications, and routines or triggers, cannot use new or changed SQL capabilities unless the effective application compatibility level is equivalent to or higher than the function level that introduced the changes. The application compatibility level applies to most SQL statements, including data definition statements (such as CREATE and ALTER statements) and data control statements (such as GRANT and REVOKE statements).
The corresponding function level or higher must be activated when you bind packages at an application compatibility level. However, if you activate a lower function level (or * function level), applications can continue to run with the higher application compatibility level. To prevent the continued use of SQL capabilities introduced in the higher function level, you must also modify the application and change the effective application compatibility level to the lower level.
For IBM data server clients or drivers that need to exploit Db2 for z/OS® capabilities that are delivered with function level V12R1M501 or greater, you need to take additional steps. See V12R1Mnnn application compatibility levels for data server clients and drivers for details.
Application compatibility levels for Db2 12 are identified by the same identifier as the corresponding function level. The format is
VvvRrMmmm, where vv is the version, r is the release, and mmm is the modification level.
Db2 12 supports the following application compatibility levels in most contexts:
- Compatibility with the behavior of the identified Db2 function level. For example,
V12R1M510specifies compatibility the highest available function level. The equivalent function level or higher must be activated. For a list of supported Db2 12 function levels, see Db2 12 function levels.
- Compatibility with the behavior of Db2 12 function level 500. This value this value has the same result as specifying
- Compatibility with the behavior of Db2 11 new-function mode. After migration to Db2 12, this value has the same result as specifying
- Compatibility with the behavior of DB2® 10 new-function mode.
For more information about application compatibility levels, see Application compatibility levels in Db2.
Star (*) function levels
You might activate a lower function level, called a star (*) function level, if you encounter problems when you activate a higher function level. In some ways function level 100* in Db2 12 is analogous to the CM* and ENFM* migration modes in previous releases. Any function level lower than the highest function level that was ever activated is always a star (*) function level.
The output from DISPLAY GROUP and ACTIVATE commands identify star (*) function levels by the function level identifier followed by an asterisk, hence the name. For example, assume that you activate function level 500 after function level 501 was previously activated. V12R1M500* in the message output indicates that the Db2 data sharing group or subsystem is at function level 500* (you might say,
function level 500 star).
Activating a lower star (*) function level by itself does not immediately disable all use of capabilities at higher function levels. Instead, it provides flexibility for limiting or disabling the use of capabilities at higher function levels, while the problems encountered in higher function levels are resolved.
At a star (*) function level, Db2 continues to tolerate objects, packages, and structures that were created or bound at higher function levels. Also, in any context where the effective application compatibility level remains at the higher level, new SQL capabilities from the higher level can still be used. For packages, they can still be executed, rebound, and automatically bound. However, an explicit bind of such packages succeeds only when the APPLCOMPAT bind option is equivalent to the activated star (*) function level or lower. Similar rules apply for the application compatibility levels of native SQL procedures, compiled SQL scalar functions, and advanced triggers. The result is that applications that use capabilities at a higher function level can continue to do so if they are not related to the reason for activating the lower function level. To stop the use of all SQL capabilities at the higher function level, you must also set all effective application compatibility levels at the lower level.