How is the APPLCOMPAT bind option determined for Database Management for Db2 for z/OS products?
Article ID: 143220
Updated On:
Products
Issue/Introduction
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?
Environment
Release : 20.0
Component: Database Management for Db2 for z/OS Suite
Resolution
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:
DSNT408I SQLCODE = -4743, ERROR: ATTEMPT TO USE A FUNCTION WHEN THE APPLICATION COMPATIBILITY SETTING IS SET FOR A PREVIOUS LEVEL
Feedback
