Activating lower (*) function levels in Db2 12

If you encounter regression or other problems after the activation of a new Db2 12 function level, you can take certain actions to minimize the impact to your applications while you resolve the underlying problems.

About this task

You might sometimes activate a lower function level, called a "star" (*) function level after 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 * function level.

The output from DISPLAY GROUP and ACTIVATE commands identify * 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).

Important: Activating a * function level does not enable you to remove maintenance and start Db2 at any code level lower than the catalog level or highest ever activated function level.

When you activate a * function level, Db2 continues to tolerate objects, packages, and structures that were created or bound at higher function levels. Some new function behaviors revert to the previous behavior immediately, especially for behaviors that do not impact SQL applications, such as new-function syntax and behaviors for Db2 commands and Db2 utilities. Db2 also continues to tolerate any subsystem parameter settings that enable capabilities of a higher function level, but Db2 might revert to the behavior of a different setting at the * function level. However, the use of new-function syntax and behaviors by SQL applications is generally not disabled at a * function level unless you take additional action, such as rebinding packages that are using them.

In application and SQL contexts, if the effective application compatibility level remains at the higher level, the SQL syntax and behaviors of the higher function level can still be used at the * function level. Packages can also still be executed, rebound, and automatically bound at the higher level. However, an explicit bind of such packages succeeds only if the APPLCOMPAT bind option is equivalent to the activated * 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 SQL 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 * 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.

Important: Do not attempt to start Db2 at any code level that is lower than the highest ever activated function level, even at the lower star (*) function level. Activate a function level only after you are satisfied that Db2 can continue to run at the required code level.

Important: Do not attempt to start Db2 at a lower code level after any part of the CATMAINT job for a higher function level completes. Run the CATMAINT job only after you are satisfied that Db2 can continue to run at the necessary code level. The code to tolerate catalog changes is contained in the code level that delivers the CATMAINT job.

Procedure

Use the following general approaches to minimize the impact of problems at a new function level, while you resolve the underlying issues:

If issues occur after you rebind packages at a higher application compatibility level, do not immediately revert to a lower star (*) function level. Instead, use REBIND SWITCH(PREVIOUS) to revert to the previous package.
This option is available only if you used PLANMGMT at the previous bind or rebind of the package.
If necessary, issue an ACTIVATE command or tailor and run job DNSTIJAF to activate the lower star (*) function level.
Activating the star (*) function level does not prevent the use of new SQL capabilities. You might continue to run applications not causing or related to the regression or problem at the higher application compatibility level. Such application can continue to use capabilities of the higher function level, unless you bind them at the lower application compatibility level.
If you must prevent all use of capabilities at the higher function level, bind all packages at the application compatibility level that corresponds to the star (*) function level.
If the default application compatibility level was set at the higher function level than the star (*) function level, reduce the default application compatibility level to that lower level to prevent bind failures.
For instructions for setting the default application compatibility, see Specifying the default application compatibility level.