search cancel

How is the APPLCOMPAT bind option determined for Database Management for Db2 for z/OS products?


Article ID: 143220


Updated On:


Database Analyzer for DB2 for z/OS Fast Unload for DB2 for z/OS Fast Check for DB2 for z/OS Fast Index for DB2 for z/OS Rapid Reorg for DB2 for z/OS Database Management for DB2 for z/OS - Administration Suite Database Management for DB2 for z/OS - Recovery Suite Database Management for DB2 for z/OS - Performance Suite Database Management for DB2 for z/OS - SQL Performance Suite Database Management for DB2 for z/OS - Utilities Suite


The APPLCOMPAT bind option is now used to bind packages during the Bind Product Plans and Packages
task in Post-Install tailoring of the Database Management Solutions for DB2 for z/OS.
The Database Management Solutions for Db2 for z/OS Bind job (ssid0002) must be regenerated and run
when Db2 is upgraded to a new Function Level. 

How do the products determine the APPLCOMPAT Bind Option?


Release : 20.0
Component: Database Management for Db2 for z/OS Suite


Below is detail on how the APPLCOMPAT Bind Option is determined:

  • The DB2 Tools will always generate an explicit APPLCOMPAT for every package in order to run in a controlled environment. 
     Different packages may be bound with different APPLCOMPAT values.  The products within the
    Db2 Tools control the
     application compatibility setting.
    The APPLCOMPAT bind value is generated based on either: Default value, SSIDVERF from the SETUPxx, or a product override.

          Common components for Db2 provide a DEFAULT value for APPLCOMPAT of V12R1M500 for Db2 12
          running at that level or higher, however
the product teams may override. 

          An example is Batch Processor (and ISQL), which is bound with the SSIDVERF from the  
SETUPxx member within hlq.CDBAPARM.

          Example 1:
           Default is V12R1M500
           Product overrides to V12R1M505
           SETUP DB2VERF is V12R1M502
           The generated APPLCOMPAT will be V12R1M502

          Example 2:
           Default is V12R1M500
           Product overrides to V12R1M502
           SETUP DB2VERF is V12R1M505
           The generated APPLCOMPAT will be V12R1M502 due to product overrides

          APPLCOMPAT on the Bind cannot be higher than the activated Function Level, which must be reflected in the SSIDVERF.

  • Batch Processor documentation:  Batch Processor

    Batch Processor packages are bound at the active Db2 function level as specified with function level (SSIDVERF) in the SETUP global parmlib member
    This enables Db2 functionality to be exploited in Batch Processor scripts for features that are associated with Db2 function levels.

  • If the function level is lower than 500, this should be reflected in SSIDVERF and bound with that value. The DB2 Administration tools will generate
    a SET CURRENT APPLICATION COMPATIBILITY with a prior level in several cases.  As an example, if level 504 is activated,
    but users still
    need to create obsolete objects, the Administration tools will use the lower level dynamically so the objects can still be created.

  •  It is critical the SETUPxx parameters SSIDVERF/SSIDVERC be kept up to date, and that the Post Install Compare/Create/Bind tasks are
     generated/executed whenever the DB2 level changes, which has been the Standard Procedure.

           Upgrade to a new DB2 Release or Function Level


Additional Information

In this example the plans are bound at a lower DB2 release level (V11), DB2 was upgraded from M100 to M501, the setup member was updated (SSIDVERF V12R1M501,  SSIDVERC V12R1M500), the BIND was not regenerated and run. The packages are still bound at V11 NFM, the ISQL select has a new parameter from V12.

Executing a SELECT thru ISQL receives: