In Part 1 of this article ( http://www.idug.org/p/bl/et/blogaid=586 ) we discussed traditional delivery and the ~3-4 year cycle of adopt, exploit, stabilize that DB2 customers have been following for the last 2 decades.  We also discussed the advantages of Continuous Delivery (CD) and the potential to improve the ability of IT organizations to deliver value.

In Part 2, we will examine how to exploit Application Compatibility (APPLCOMPAT) which was introduced in DB2 11, and Function Levels which is introduced in DB2 12 to safely manage change.   The levels of APPLCOMAT you can specify is limited by the Function Level of your system, so we will first talk about function levels.


Introduction to Function Levels


DB2 has had been using function levels since DB2 V8 to distinguish when new features are available to be used.  This same mechanism is the same for DB2 V8- DB2 11.  For example, if you connected to DB2 11 in CM you would see something like the following:

  Database Connection Information

 Database server        = DB2 z/OS 11.1.1

 SQL authorization ID   = SYSADM

 Local database alias   = DB2A


Connecting to the same DB2 11 system in NFM would provide the following:


 Database Connection Information   

 Database server        = DB2 z/OS 11.1.5

             SQL authorization ID   = SYSADM

             Local database alias   = DB2A


This information was provided on various interfaces and could be used by customers or vendors to determine the capabilities of the DB2 system.  The IBM Data Server Drivers (ODBC/CLI and JDBC drivers) have used this mechanism to determine when DB2 was in NFM and capable of exploiting new function.  In the past, DB2 reserved Mod levels 1-4 for CM and 5-9 for NFM.


In DB2 12, the previous function level capability has been extended with two additional bytes.  Before new function is available is 12.1.100 and after new function is available is 12.1.500.  More formally these are discussed in the DB2 manuals as V12R1M100 and V12R1M500.  As new function is made available in DB2 12, customers will make that function available using the –ACTIVATE FUNCTION LEVEL command.  The –ACTIVATE command is also used to enable the DB2 base new function capability.  As shown below in Figure 1, –ACTIVATE FUNCTION LEVEL(V12R1M500) is used to enable base DB2 12 new function.


DB2 12 Migration

 chris fig1.png

Figure 1


As you can see in Figure 1, a customer running DB2 V11 (in Orange) would start a member of a datasharing group with DB2 12 libraries (in Green).  Once that member was started, the only thing that the member could do would be to run DSNTIJTC to update the catalog.  Once DSNTIJTC is complete, the catalog for DB2 12 is ready for the DB2 12 member to be an active part of the datasharing group.  After some period (which will vary by customer), all members are running DB2 12.  When the customer is sure that they no longer would want to fall back to DB2 11, they would issue –ACTIVATE to enable new DB2 12 capability.   As with previous releases, DB2 12 does support going to a previous level (a “*” Mode) by issuing –ACTIVATE to a previous (lower) function level (more on that later).


A Simple Function Level Activation


Once a customer has activated DB2 base function (V12R1M500), they may decide that there is new function available in DB2 12 that they want to exploit. To activate a new function level, the –ACTIVATE command is used.  For example




                        *** BEGIN ACTIVATE FUNCTION LEVEL (V12R1M501)     

                                                            FUNCTION LEVEL (V12R1M501) SUCCESSFULLY ACTIVATED                                                                                                                                    


                        CURRENT FUNCTION LEVEL(V12R1M501)    


HIGHEST POSSIBLE FUNCTION LEVEL(V12R1M501)                                                                           




Figure 2 shows a simple activation of function level V12R1M501. 

chris fig2.png Figure 2

 In Figure 2, a system running with maintenance capable of supporting DB2 12 base function is running (in Orange).  A datasharing member is rolled in with higher maintenance (in Green).  After about 1 week, the other systems are all running on the new maintenance.  Once the customer is comfortable with the maintenance, they choose to activate the new function available in V12R1M501.  In Figure 2, this is shown by the red bar on the left of the figure, and the –ACTIVATE FUNCTION LEVEL(V12R1M501) box in blue.  Once this command is executed, the function that was shipped in V12R1M501 is available.  Additionally, any maintenance that supports functions provided in Function Level V12R1M501 must remain on the system, or DB2 will not start.  This maintenance level check is enforced by DB2 during startup.


Function Level Activation in the Real World


Best practice is to apply maintenance 2-4 times a year, and many customers follow this practice – often using quarterly Recommended Service Updates(RSUs).  Since activating a function level requires that maintenance to support that function level remain applied to the system, we anticipate that customers will be conservative in activating a function level.


Many customers follow a simple SMPE strategy.  They RECEIVE and APPLY an RSU level, but do not ACCEPT the maintenance until they are ready to start the next maintenance cycle.  This allows the customer to REJECT any maintenance that may be causing a problem if needed until their next maintenance cycle.   At the start of the next maintenance cycle, the customer ACCEPTs the previous maintenance, and starts over with a new RECEIVE and APPLY cycle.  Given this paradigm, it is reasonable to assume that most customers will not activate a function level until they have done an “ACCEPT” on that maintenance.  For example, if a customer does two maintenance cycles a year, this equates to a lag of about 6 months between the time that maintenance is applied, and the time that a customer would consider activating that function level.  Of course, function could be made available in development environments in a more aggressive manner if specific capabilities are needed for a development project.


Figure 3 shows a typical activation of a set of function levels, including a catalog change, as part of a normal cycle of applying maintenance.

chris fig3.png 

Figure 3


In this example, a customer is running a sysplex on maintenance capable of supporting DB2 V12R1M502 (in Orange).  As part of a yearly maintenance cycle, the customer applies maintenance capable of supporting DB2 V12R1M507 and starts one member (in Green).  After about a week, all members are running the new maintenance.  When the customer is ready, they would run the CATMAINT that is required for function level V12R1M505, and activating the new function level V12R1M507.  The CATMAINT, like the activation of a function level, will lock in the maintenance required for that function (in this case, the catalog).  After the CATMAINT is complete, the customer would likely immediately activate function level V12R1M507 since that was their real goal (to activate the higher level functional capability).   After the –ACTIVATE is issued, DB2 V12R1M507 capability is available across the sysplex.  The customer can then choose to enable that new capability in applications on a package by package basis, as necessary for their applications.


 Safely Adopting a new Function Level[i]


  • PTFs (RSUs…) are applied as normal
    • These PTFs may include PTFs that enable new function in DB2.
    • Proceed with normal testing and promotion to ensure system stability on new maintenance  
  • Update DB2 Catalog (catmaint) if required to advance the function level


      • After execution of catmaint, the system can only be started with a CL that supports the catalog
      • Activate Function Level
          • Function not related to SQL, DML, DCL syntax is available
          • REBIND of packages with any APPLCOMPAT would pick up optimizer enhancements
          • non-stabilized dynamic SQL would pick up optimizer / other non-APPLCOMPAT related enhancements

Introduction to Application Compatibility (APPLCOMPAT)

DB2 11 introduced the concept of Application Compatibility. DB2 11 has a DB2 10 mode - APPLCOMPAT(V10R1) and a DB2 11 Mode - APPLCOMPAT(V11R1). DB2 12 additionally adds a DB2 12 mode – APPLCOMPAT(V12R1M500). Once you have activated function level V12R1M500, you can bind applications with APPLCOMPAT(V12R1M500) and start exploiting DB2 12 capabilities. By the time most DB2 customers adopt DB2 12, they will also have to opportunity to adopt additional capability that DB2 has shipped in function levels beyond V12R1M500.As shown in Figures 1-3, the values you can specify for APPLCOMPAT are limited by the Function Level of your system. With one exception, you may only specify an APPLCOMPAT value that is less than or equal to your Function level. Figure 4, shows the exception to that rule.

chris fig4.png

Figure 4    

Figure 4 shows a system running with an V12R1M500 catalog level, and code libraries capable of supporting V12R1M501.  In fact the Function Level of the system has already been advanced to V12R1M501.  At a point in time indicated by the RED bar, the customer issues –ACTIVATE FUNCTION LEVEL(V12R1M500).  This command will take the system to Function Level V12R1M500.  The code libraries for DB2 must remain capable of supporting Function Level V12R1M501


After the –ACTIVATE command is issued, the system will prevent NEW exploitation of V12R1M501 functionality.  Applications currently bound with V12R1M501 will continue to work as before, and may be rebound using the REBIND command.  New applications may not be bound (BIND) using an APPLCOMAPT value that is higher than the new function level (V12R1M500). 


When a new Function Level is adopted, not every application in the system with be bound (BIND or REBIND) with an APPLCOMPAT value equal to that new function level.  Instead, we expect that customers will establish a base APPLCOMPAT value for an application (a set of packages) during a development and test cycle for that application.  Changes to the APPLCOMPAT value for an existing application would only be made at the next development cycle for that application (if needed).  DB2 12 still supports DB2 10 compatibility – this clearly demonstrates IBMs commitment to support stable application execution environments for our customers.


Safely Adopting a new Application Compatibility Level


  • After Function Level is considered stable - allow new application feature rollout.
    • REBIND DBA packages to allow new DDL to be utilized
    • BIND new application static packages with higher APPLCOMPAT to exploit DDL/DML new functions/behaviors. There is no reason to REBIND existing applications unless they need to exploit new capability.
    • REBIND dynamic packages with higher APPLCOMPAT to allow new SQL functions to be used
    • REBIND distributed packages (***in new collection) to allow new SQL functions to be used
      • Switch applications that need to use new function to the new distributed package collection
    • Leverage PLANMGMT extended
      • REBIND SWITCH (PREVIOUS) to restore static to prior runtime structures
      • REBIND SWITCH (PREVIOUS) for dynamic would restore prior APPLCOMPAT
      • ***switching to prior collid for distributed dynamic would restore APPLCOMPATIn DB2 11, APPLCOMPAT controlled the behavior of SQL and XML and could be specified on BIND/REBIND or by using SET CURRENT APPLICATION COMPATIBILITY special register. The default for the special register, which affects dynamic SQL, is the value specified for APPLCOMPAT on the bind.In DB2 12, APPLCOMPAT was extended to control the behavior of DDL and DCL (Grant, Revoke, …) in addition to SQL and XML. With this new capability, applications can be tested and deployed at a specific APPLCOMPAT level, and will remain stable, even as new capabilities are added to DB2 and enabled though the activation of a function level.



The infrastructure that DB2 has put in place for DB2 12, enables customers to receive preventive service and new function in the same stream. Function Levels give customers the choice when to enable access to new function when the customer is ready to adopt that function, and APPLCOMPAT provides an island of stability for an application across releases and functions levels.The highlights of the enhancements to DB2 that provide the basis to safely adopt new change in a continuous delivery environment have been covered here, but there are many details that were not covered. I encourage you to listen to the webinar that John Campbell and I did recently ( http://event.on24.com/wcc/r/1226555/5D5D156061E7D1176B693C06FD8FA0C1 ), or attend a session at IDUG or WOW to get the latest information this important new initiative from IBM 

Chris Crone

IBM Distinguished Engineer




[i] I would like to thank Patrick D. Bossman (https://www.linkedin.com/in/bossman ) for contributing to the Best Practices for safely adopting new Function Levels and Application Compatibly Levels discussed in this article.

Recent Stories
Running Db2 for z/OS utilities from the application programs (DSNUTILU as a piece of DevOps)

DevOps and Db2 for z/OS

September Content Recap