Function level 509 (APAR PH70028 - April 2026)

Function level 509 introduces support for converting non-UTS catalog and directory table spaces to UTS, TRANSFER OWNERSHIP for certain application objects, subnet IP address filtering for the RLF, utility history for the SHRLEVEL option, catalog columns for STMT_HASHID2, I/O counts in RTS, and reduced false page P-lock contention for certain page sets in data sharing.

Contents

Converting Db2 catalog table spaces to UTS

Subnet wildcard filtering for resource limit facility (RLF)

Online ownership transfer of application objects

Utility history for SHRLEVEL information

New catalog columns for STMT_HASHID2

I/O counts in real time statistics

Reduced false page P-lock contention in data sharing

How to activate function level 509

Enabling APAR: PH70028
Full identifier: V13R1M509
Catalog level required: V13R1M509
Product identifier (PRDID): DSN1301A
Incompatible changes: None

New capabilities in function level 509

Function level 509 activates the following new capabilities in Db2 13.

Converting Db2 catalog table spaces to UTS

Function level 509 enables a process for converting tables spaces for Db2 catalog and directory tables from deprecated non-UTS types to partition-by-growth universal table spaces (PBG UTS).

Adopting UTS across the board for catalog and directory objects means that Db2 can then take advantage of new performance, availability, and usability features that have been added exclusively for UTS objects. The conversion process for the Db2 catalog began with DB2® 10 and continued in Db2 11. Although much of the catalog and directory objects were converted to UTS during the (enabling new function mode) processes for those previous releases, the conversion process was not completed for all Db2 catalog and directory objects.

When you are ready, you can use the REORG TABLESPACE utility with the new CONVERTUTS option to convert the catalog objects. You can customize and run the DSNTIJCR sample job to complete the conversion for all remaining non-UTS table spaces in the Db2 catalog and directory. You do not need to run the installation CLIST to tailor this job. For information about how to customize it for your Db2 environment, see the job prolog.

For more information, see the following related topics:

Subnet wildcard filtering for resource limit facility (RLF)

Starting with Function Level 509, the Resource Limit Facility (RLF) supports IPv4 and IPv6 subnet wildcards and local application thread governing. These enhancements reduce the number of rows that are required in the DSNRLMTxx table by allowing a single row to govern entire network blocks.

Function level 509 introduces capabilities that reduce the number of resource limit facility (RLF) table rows that customers must maintain and simplify the management of large client environments. This function level extends the DSNRLMTxx table to accept IPv4 and IPv6 subnet wildcard formats, allowing a single row to represent an entire network block instead of many individual IP addresses.

Function level 509 also adds support for the local IP address 127.0.0.1, which allows RLF rules to apply only to SQL originating from the local Db2 subsystem. Exact IP address rows take precedence over subnet rows, and rows with invalid subnet prefix values are ignored. These enhancements improve flexibility and efficiency when defining and applying RLF rules.

For more information, see the following related topics:

Online ownership transfer of application objects

Function level 509 enables security administrators to satisfy business security mandates without causing an application outage, by introducing syntax in the TRANSER OWNERSHIP statement for application objects, such as stored procedures, functions, and sequences. That is, starting at APPLCOMPAT level V13R1M509, the following new syntax options can be specified in TRANSFER OWNERSHIP statements. Authorization for transfer ownership must include ownership of the object or SECADM authority.

  • function-designator
  • PROCEDURE procedure-name
  • SEQUENCE sequence-name

Before this enhancement, changing the ownership of these objects can require disruptions including invalidation of packages that use the object, and sometimes cascaded drops of dependent objects, often leading to application outages.

The TRANSFER OWNERSHIP statement was originally introduced in Db2 12 to enable transferring ownership of database and system objects.

For more information, see the following related topics:

Utility history for SHRLEVEL information

Function level 509 enhances the utility history information in the Db2 catalog to record the SHRLEVEL option that was in effect for each utility. Database administrators and IBM® Support can use this information to determine when concurrency problems might be caused by the SHRLEVEL option used for utility executions.

For more information, see the following related topics:

New catalog columns for STMT_HASHID2

Function level 509 makes more-granular hash values that can be used to identify specific static SQL statements available, by adding columns named STMT_HASHID2 and STMT_HASH2VER in the SYSIBM.SYSPACKSTMT and SYSIBM.SYSPACKSTMTCOPY catalog tables.

The hash key values in the STMT_HASHID2 columns in these tables are based on the normalized statement text with other information such as the package name, collection ID, and selected bind options. The VERSION name is not used for the hash key value.

The existing QUERY_HASH column values in these tables are similar, but their hash keys are generated based on the SQL statement text only, so the values do not uniquely identify the situations where statements with identical statement text are issued from different packages, with different bind options, or with different PREPARE attributes.

Similar columns are already available for EXPLAIN records in the DSN_STATEMNT_TABLE and DSN_STATEMENT_CACHE_TABLE tables.

For more information, see the following related topics:
I/O counts in real time statistics

Function level 509 introduces object‑level synchronous read I/O data into real‑time statistics (RTS) to support improved analysis of read I/O behavior over time. This enhancement adds two NSYNCREADIO columns to the SYSIBM.SYSTABLESPACESTATS and SYSIBM.SYSINDEXSPACESTATS RTS tables to record the count of synchronous read I/O operations at the object level.

The NSYNCREADIO columns complement the existing GETPAGES metric by providing object‑level insight into synchronous read I/O, similar to the insight provided by QBSTRIO at the SQL query block level. This capability enables DBA tools and Db2ZAI to analyze and detect anomalies in object behavior more effectively.

For more information, see the following related topics:

Reduced false page P-lock contention in data sharing

Function level 509 reduces false page P-lock contention in data sharing environments by introducing a new lock hash algorithm for page sets of objects other than PBR RPN table spaces. The enhancement applies to page sets where the DSSIZE is greater than 64 GB and the page size is 4 KB or the DSSIZE is greater than 128 GB and the page size is 8 KB. These page sets include user objects as well as catalog and directory objects that might experience increased false page P-lock contention when they are converted to PBG UTS through the CATMAINT process.

To benefit from this enhancement, existing page sets must be reformatted after function level 509 is activated. You can use one of the following utilities: REORG TABLESPACE, REORG INDEX, REBUILD INDEX, or LOAD REPLACE. Page sets that are created after function level 509 is activated automatically use the new algorithm, so they are not affected by the false page P-lock contention.

V13R1M509 application compatibility

Most new SQL syntax and behaviors introduced by this function level become available when applications run at the equivalent application compatibility (APPLCOMPAT) level or higher. Otherwise, the result is a SQL code error such as -4743, or sometimes a previous behavior continues as before. For more information, see the following topics:

How to activate function level 509

The following steps summarize the process for activating this function level. To learn more about how to activate and control the adoption of new capabilities available for use in your Db2 13 environment and continuous delivery in general, see Adopting new capabilities in Db2 13 continuous delivery.

Before you begin
Important: When you activate a function level in Db2 13, all lower function levels are also activated. If your Db2 13 environment is not already at the next lower function level, review all new capabilities that will be activated. For a complete list of capabilities by function level, see Db2 13 function levels.
Procedure

To activate function level 509, complete the following steps:

  1. If Db2 13 is still at function level 100, activate function level 500 first. For more information, see Activating Db2 13 function level 500 or higher.
  2. Generate tailored JCL jobs for the CATMAINT and function level activation steps. Start of changeYou can use the DSNTIJBC batch job or the Db2 installation CLIST.End of change
    Tip: You can avoid working through the Db2 installation CLIST panels in interactive mode by running a batch job with valid input files to generate the required JCL jobs and input files with a background process. See Generating tailored Db2 migration or function level activation jobs in the background.
    Start of changeTo generate the required JCL jobs and input files with a background process, complete the following steps:End of changeStart of change
    1. Customize the DSNTIDOA parameter override file by following the instructions in the file.
    2. Customize the DSNTIJBC job. For example, if prefix.SDSNSAMP(DSNTIDOA) is the customized parameter override file, you can specify the following values in the ISPSTART command in DSNTIJBC.
        ISPSTART CMD(%DSNTINSB + 
    OVERPARM(prefix.SDSNSAMP(DSNTIDOA)) + 
    ) BREDIMAX(1)
    3. If you use Db2 Value Unit Edition, you must also provide the data set name of the DSNTIDVU parameter override file in the IPSTART command in the DSNTIJBC job, as shown in the following example, where prefix.SDSNSAMP(DSNTIDVU) is the customized OTC LICENSE file.
        ISPSTART CMD(%DSNTINSB + 
    OVERPARM(<prefix>.SDSNSAMP(DSNTIDOA)) + 
    OTCLPARM(<prefix>.SDSNSAMP(DSNTIDVU)) + 
    ) BREDIMAX(1)
    4. Submit the customized DSNTIJBC job.
    End of change
    Start of changeTo generate the required JCL jobs and input files with the Db2 installation CLIST in interactive mode, complete the following steps:End of change
    1. In panel DSNTIPA1, specify INSTALL TYPE ===> ACTIVATE. Then, specify the name of the output member from the previous function level activation (or migration) in the INPUT MEMBER field, and specify a new member name in the OUTPUT MEMBER field.
    2. In panel DSNTIP00, specify the current function level and TARGET FUNCTION LEVEL ===> V13R1M509. The Db2 installation CLIST uses this value when it tailors the ACTIVATE command in the DSNTIJAF job and the CATMAINT utility control statement in the DSNTIJTC job.
    3. Proceed through the remaining Db2 installation CLIST panels, and wait for the Db2 installation CLIST to tailor the jobs for the activation process. The output data set contains the tailored jobs for the activation process. For more information, see The Db2 installation CLIST panel session.
  3. Check that Db2 is at a sufficient code level by issuing a DISPLAY GROUP command. For more information, see Determining the Db2 code level, catalog level, and function level. The DSN7100I message indicates the Db2 code level for under DB2 LVL in the member details.
    Tip: You can apply any PTF at any function level. It is best to run Db2 at this code level or higher for some time before you proceed with activating the function level. Db2 cannot run at any lower code level after you activate a function level, so you cannot remove any of the required PTFs after you activate a function level.
  4. Ensure that no incompatible applications will interfere with the catalog update. For details, see Identifying applications that are incompatible with catalog updates.
  5. Update the catalog and verify the changes for function level 509 by completing the following steps. If the Db2 catalog is already at the catalog level required for the function level being activated, you can skip this step.

    1. Run the DSNTIJIC job to take an image copy of the Db2 catalog and directory.

      Important: After you apply the PTF for APAR PH66270 and until you stop and restart Db2, the DSNTIJIC job might return the following error messages:

      For more information, see PH66270.

    2. Run the tailored DSNTIJTC job, or run the CATMAINT utility with LEVEL V13R1M509, to update the catalog to the appropriate catalog level.

      If multiple catalog updates are required, the CATMAINT job processes each update in sequential order. If a later update in the sequence fails, the previous successful updates do not roll back, and the catalog level remains at the highest level reached. If that occurs, you can correct the reason for the failure and resubmit the same CATMAINT job.

      For information about the changes to the catalog, see Catalog changes in Db2 13.

    3. If the CATMAINT utility jobs from the previous step placed any altered Db2 catalog objects in REORG-pending (AREO*) advisory status, run the REORG utility for those objects.
    4. Run the generated DSNTIJX2 job to run the CHECK INDEX utility for Db2 catalog and directory indexes for new objects created in Db2 13.
  6. Check that Db2 is ready for function level activation by issuing the following ACTIVATE command with the TEST option:
    -ACTIVATE FUNCTION LEVEL (V13R1M509) TEST
    Db2 issues message DSNU757I to indicate the results. For more information, see Testing Db2 function level activation.
  7. Run the tailored DSNTIJAF job, or issue the following ACTIVATE command:
    -ACTIVATE FUNCTION LEVEL (V13R1M509)

  8. If you are ready for applications to use new SQL capabilities in this function level, rebind the applications at the equivalent application compatibility level for higher. For more information, see the following topics:

    Optionally, when you are ready for all applications to use the new capabilities of the target function level, you can run the following jobs:
    1. Run DSNTIJUZ to modify the subsystem parameter module with the APPLCOMPAT value that was specified on panel DSNTIP00.
    2. Run DSNTIJOZ job to issue SET SYSPARM command to bring the APPLCOMPAT subsystem parameter changes online.
    3. Run DSNTIJUA job to modify the Db2 data-only application defaults module with the SQLLEVEL value that was specified on panel DSNTIP00.