Controlling the Db2 application compatibility level

You can use the application compatibility level of your applications to control the adoption of new capabilities and enhancements, and the impact of incompatible changes. That is, you can separate the Db2 12 migration and function level activation processes from application updates to adopt new features and resolve incompatible changes.

Before you begin

Activate the function level that introduces the new SQL capabilities that your applications will use. For details, see Adopting new capabilities in Db2 12 continuous delivery.

To control the adoption of new SQL capabilities, and the impact of incompatible changes on your Db2 applications, and objects such as routines and triggers, use the following process:

1. After the activation of a new function level (including function level 500 after migration to Db2 12), continue to run your applications at the same application compatibility level until you are satisfied that your Db2 12 environment is stable at the new function level.
2. Rebind the packages for SPUFI and the productivity-aid sample programs (such as DSNTEP2, DSNTEP4, DSNTIAD, and DSNTIAUL) at the higher application compatibility level, so that database administrators can begin using the new SQL data definition capabilities.
   For more information about preparing the sample programs, see Db2 productivity-aid sample programs.
3. Identify the highest priority applications for the use of new capabilities. Then, identify and resolve any incompatibilities, as described in Managing application incompatibilities.
4. Bind or rebind your high-priority applications at the higher application compatibility level.
   For best results, apply the following approaches when you complete this step:

   • Rebind packages for static SQL applications. Specify use of the PLANMGMT bind option so that you can revert to a previous package copy if a regression occurs.
   • Rebind packages for dynamic SQL applications. The application compatibility level is also among the matching criteria for both cached and stabilized dynamic statements. When it changes, cached dynamic statements exit the cache and require a full prepare at the next execution, and stabilized dynamic SQL statements are no longer stabilized and subject to full prepare and access path change. It is best to re-stabilize such statements only after you are satisfied that no access path regression has occurred.
   • Rebind distributed packages in separate collections and switch the applications to using the new collections.

   Tip: Extra program preparation steps might be required to increase the application compatibility level for applications that use data server clients or drivers to access Db2 for z/OS. For more information, see Setting application compatibility levels for data server clients and drivers.
5. Repeat the two preceding steps for any applications, and any objects such as routines or triggers, that require the use of new SQL capabilities.
6. After incompatible changes are resolved for most applications, rebind any remaining applications that must continue to run compatibly with the lower level, and explicitly specify the lower application compatibility level.