DB2 function levels and APPLCOMPAT

Why DB2 uses function levels

Starting with Db2 12, IBM moved Db2 for z/OS to a continuous deliverymodel. A traditional release still supplies a major migration boundary, but many later enhancements arrive in maintenance rather than waiting for another large release. A function level identifies a tested group of those enhancements and provides a deliberate switch that enables them.

The switch matters because production systems need control. Installing maintenance on a member should not unexpectedly change SQL syntax or application behavior. A team can install code, verify that every member is ready, update the catalog when required, test in lower environments, and only then activate the target function level. Applications can adopt the new SQL level later through APPLCOMPAT.

Code level, catalog level, function level, and application level

These levels are related, but they answer different questions. Confusing them is one of the most common beginner mistakes. The code level says what the installed Db2 code can support. The catalog level says whether the catalog structure can represent the required metadata. The function level says what the subsystem currently allows. Finally, APPLCOMPAT says what a package is allowed to use.

A member can therefore run code that understands V13R1M501 while the group remains at V13R1M500. The catalog can be prepared for a capability that is not active yet. After activation, an important package can remain bound at an older APPLCOMPAT until its regression testing is complete. Advancement flows downward through these gates; it is not one automatic upgrade event.

Understanding function-level names

A value such as V13R1M501 identifies version 13, release 1, modification or function level 501. Level 100 is associated with migration-level operation, while level 500 is the major new-function baseline for the release. Levels above 500, such as 501, represent incremental continuous-delivery capability. Exact available levels depend on the maintenance installed in your environment.

An asterisk is operationally significant. A value such as a documented V13R1Mnnn* is a fallback function-level state, not a higher numbered feature level and not decorative output. Always use the exact fallback target supported by your Db2 level and IBM procedure; do not invent a starred value from a normal level.

Checking current levels with DISPLAY GROUP

Before planning any change, issue -DISPLAY GROUP. Its output identifies the group, members, release code capability, catalog level, and current function level. In data sharing, check every member rather than assuming that one member represents the whole group. Maintenance differences can prevent activation.

1
2
3
4
5
6
7
8
-DISPLAY GROUP
 
Review the output for:
  DB2 system or group level
  DB2 code level for each member
  Catalog level
  Current function level
  Highest possible function level supported by installed code

Keep the command output with the change record. Run it before maintenance, after all members have been updated, immediately before activation, and after activation. That simple evidence makes it much easier to diagnose a member mismatch or prove what changed.

Function level activation

Activation is a planned subsystem action. The core command is -ACTIVATE FUNCTION LEVEL. IBM supplies installation job DSNTIJAF to drive the process in a controlled way. Your installation team customizes the job for the subsystem, confirms prerequisites, obtains change approval, and submits it according to local standards.

1
2
3
4
5
6
-ACTIVATE FUNCTION LEVEL(V13R1M501)
 
-- Typical operational sequence:
-DISPLAY GROUP
-- submit the tailored DSNTIJAF activation job
-DISPLAY GROUP

Db2 validates the request. The code and catalog must support the target, and group conditions must satisfy the rules for that level. Do not treat a successful command as permission to skip application testing. Activation makes subsystem capability available; application packages still control their SQL compatibility through APPLCOMPAT.

The special importance of V13R1M500

V13R1M500 is more than an ordinary incremental activation. It establishes Db2 13 new-function operation. Activating it prevents supported coexistence with and fallback to the prior Db2 release. Before this point, a migration plan can retain the documented route back to Db2 12. After this point, the team must move forward within Db2 13 recovery and fallback rules.

That irreversible release boundary deserves explicit approval. Confirm that all members are on Db2 13, prior-release coexistence is no longer needed, catalog work is complete, operational tooling is compatible, and recovery procedures have been tested. Activation does not automatically rebind packages to V13R1M500, so application adoption can still be staged.

APPLCOMPAT for packages

APPLCOMPAT is a BIND or REBIND option that chooses an application compatibility level for a package. It controls the SQL syntax, semantics, and selected incompatible changes that static SQL in that package can use. This package-level gate is the reason a subsystem can advance without forcing every application to change on the same weekend.

1
2
3
4
5
6
BIND PACKAGE(PAYROLL.COLLID) -
     MEMBER(PAYPGM) -
     APPLCOMPAT(V13R1M500)
 
REBIND PACKAGE(PAYROLL.COLLID.PAYPGM) -
       APPLCOMPAT(V13R1M501)

You cannot BIND or REBIND APPLCOMPAT higher than the current function level. If the group is at V13R1M500, requesting APPLCOMPAT(V13R1M501) fails even when code for 501 is already installed. The subsystem function must be activated first. Conversely, a group at 501 can continue running packages bound at 500 or another supported lower level.

Inventory package values in the catalog before migration. Group packages by owner and business criticality, test representative SQL, then raise APPLCOMPAT in waves. Preserve package copies or versions according to your package fallback procedure. Avoid rebinding everything at the newest level merely because the activation succeeded.

CURRENT APPLICATION COMPATIBILITY

Dynamic SQL uses the package APPLCOMPAT as its ceiling and initial compatibility value. The CURRENT APPLICATION COMPATIBILITY special register, also referenced with the APPLCOMPAT abbreviation, can lower the compatibility level for subsequent dynamic statements in the application process. It cannot raise the session above the APPLCOMPAT value with which the active package was bound.

1
2
3
4
5
6
7
SELECT CURRENT APPLICATION COMPATIBILITY
  FROM SYSIBM.SYSDUMMY1;
 
SET CURRENT APPLICATION COMPATIBILITY = 'V13R1M500';
 
-- This cannot exceed the allocated package APPLCOMPAT:
SET CURRENT APPLICATION COMPATIBILITY = 'V13R1M501';

This distinction is useful for JDBC, CLI, stored procedures, and other dynamic workloads. If new syntax receives a compatibility error, inspect both the active subsystem function level and the APPLCOMPAT of the package collection being used. Raising only the special register cannot bypass an older package.

Fallback

The word fallback is used for two different ideas. Release fallback means returning to the prior Db2 release during the supported migration window. Function-level fallback means activating a documented starred level to restrict certain enabled behavior within the current release. Neither should be confused with restoring a complete subsystem backup.

Before V13R1M500, the migration procedure can preserve a documented route to the prior release. Activating V13R1M500 ends that coexistence and release-fallback capability. A later starred fallback function level cannot recreate it. This is why the level-500 decision must be separated from routine maintenance activation.

Fallback procedures

When IBM support documentation directs you to a fallback function level, use the same controlled activation mechanism and specify the exact lower fallback target with its asterisk. A representative command form is shown below; the actual supported value must come from documentation for your installed code.

1
2
3
-DISPLAY GROUP
-ACTIVATE FUNCTION LEVEL(V13R1M500*)
-DISPLAY GROUP

The starred activation changes the enabled subsystem behavior to the documented fallback state. It can stop use of capabilities above that fallback boundary and prepare the group for the recovery action IBM defines. It does not uninstall PTFs, replace executable code, reverse catalog migration, drop newly created objects, convert data, lower package APPLCOMPAT values, or undo SQL already executed.

A safe procedure begins by stopping adoption of the affected functions. Identify packages rebound at newer APPLCOMPAT values and applications using newer SQL. Follow documented package rebind or copy-switch steps, quiesce workloads if required, capture DISPLAY GROUP, activate the supported starred level, and verify every member. If a catalog or data change must be reversed, use its specific recovery plan; do not expect the ACTIVATE command to do that work.

• Confirm the reason for fallback and involve IBM Support for uncertain production cases.
• Check the target starred level against installed code and official migration guidance.
• Stop applications from using functions that are unavailable at the fallback level.
• Handle package APPLCOMPAT and package copies as a separate application task.
• Verify command output, catalog health, member consistency, and critical transactions.

Practical rollout strategy

Treat each gate as its own change. First install maintenance and prove member consistency. Next complete required catalog work. Then activate the function level with DSNTIJAF and validate subsystem behavior. Finally, let application teams raise APPLCOMPAT in small, tested groups. This approach limits the number of variables changed at once and gives each team a clear rollback responsibility.

Document the starting and target levels, DISPLAY GROUP output, package collections, owners, test evidence, activation command, fallback boundary, and post-change checks. Function levels provide flexibility, but only disciplined records turn that flexibility into a safe production process.

Explain it like I'm 5

Imagine a toy box with new electronic toys. The code level means the toys are in the box. The catalog level means the instruction shelf has space for their manuals. The function level is the parent turning on the power. APPLCOMPAT is each child's permission card: one child can keep using familiar toys while another learns the new one. A fallback star turns off some new buttons, but it does not remove the toys, erase the manuals, or undo games already played.

Exercises

1. Read sample -DISPLAY GROUP output and identify the code, catalog, and function levels. Explain why the three values might differ.
2. Write a pre-activation checklist for V13R1M501 that covers members, catalog readiness, DSNTIJAF, application testing, evidence, and fallback limits.
3. A group is at V13R1M500 and a package requests APPLCOMPAT(V13R1M501). Predict the result and list the correct order of actions.
4. Compare package APPLCOMPAT with CURRENT APPLICATION COMPATIBILITY. State which value is the ceiling and why the special register cannot bypass it.
5. Explain what V13R1M500 activation changes about prior-release coexistence and why activating V13R1M500* later would not reconstruct a Db2 12 fallback path.