DB2 Tools; How is the APPLCOMPAT Bind option determined for Database Management for DB2 for z/OS products?


Article ID: 143220


Updated On:


CA Database Analyzer for DB2 for z/OS CA Fast Unload for DB2 for z/OS CA Fast Check for DB2 for z/OS CA Fast Index for DB2 for z/OS CA Fast Load for DB2 for z/OS CA Rapid Reorg for DB2 for z/OS CA 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 CA Database Management Solutions for DB2 for z/OS. 
The CA 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

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 can be bound with a different APPLCOMPAT  The products within the
    DB2 Tools control the application compatibility setting,  the APPLCOMPAT  generated is 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 PARMLIB.

          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, but now 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 VERF/VERC 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: