Responding to problems after function level activation
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 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.
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 Enabling default application compatibility with function level 500 or higher.