Function level 502 (APAR PH47891 - October 2022)

Function level 502 introduces Db2 controlled sysplex workload balancing (WLB) and infrastructure for statement-level invalidation.

Contents

Enabling APAR: PH47891
Full identifier: V13R1M502
Catalog level required: V13R1M501
Product identifier (PRDID): DSN13013
Incompatible changes: None

New capabilities in function level 502

Function level 502 enables the following new capabilities in Db2 13.

Db2 controlled sysplex workload balancing
Starting in function level 502, you can enable sysplex workload balancing (WLB) on a Db2 for z/OS® server.

sysplex WLB functionality (also called transaction-level workload balancing) on Db2 for z/OS servers provides high availability for client applications that connect directly to a data sharing group by balancing work among members of a data sharing group at the start of a transaction. Db2 for z/OS server returns a list of available members with weights provided by WLM . At the start of a transaction, the client application chooses the member with the best weight from the list. Configuration parameters are available on clients (Java and non-Java) to enable this functionality.

To enable use of this new capability, function level 502 introduces the following new keywords for the -MODIFY DDF (Db2) command.

Start of changeRQSTWLBEnd of change
Start of change Specifies that Db2 returns to the remote client a request to enable sysplex workload balancing. This option can only be specified if the subsystem is part of a data sharing group. This option has group-wide scope. The decision to honor sysplex workload balancing request lies with the client.
Notes:
  • The RQSTWLB option applies for Db2 for Linux®, UNIX, and Windows 11.5 or later (CLI Db2 code release "SQL11050" and IBM® Data Server Driver for JDBC and SQLJ 4.26.14 or later.)
  • If RQSTWLB is used, applications might encounter additional communication errors such as SQL codes -30108 and -20542. Start of changeThese errors are removed by default with Db2 11.5.8 or later client drivers, and the client property enableseamlessfailovererrorcodes controls whether they are issued.End of change
*
The option is enabled for entire data-sharing group. This is the default option.
location-name
The option is enabled for remote clients that access the data-sharing group using the location-name as the data source.
alias-name
The option is enabled for remote clients that access the data-sharing group using the specified alias-name as data source.
End of change
Start of changeDFLTWLBEnd of change
Start of change Db2 honors the sysplex workload balancing option requested by the client. This option can only be specified if the subsystem is part of a data sharing group. This option has group-wide scope. DFLTWLB is the default installed option.
*
The option is enabled for entire data-sharing group. This is the default option.
location-name
The option is enabled for remote clients that access the data-sharing group using the location-name as the data source.
alias-name
The option is enabled for remote clients that access the data-sharing group using the specified alias-name as data source.
End of change

PH48253 delivered the functional code for Db2 controlled sysplex workload balancing.

Record dependencies and validity at the statement level for packages

Starting in function level 502, when a package is bound or rebound with the new DEPLEVEL(STATEMENT) option, package invalidation is handled at a statement level. If one or more statements in a package are invalidated, a value of 'S' is recorded in the VALID column of the SYSPACKAGE or SYSPACKCOPY catalog table to indicate that the package is partially invalidated. The VALID column of the SYSPACKSTMT or SYSPACKSTMTCOPY catalog tables indicates the specific statement that is invalidated. In function level 503 or lower, a partially invalidated package is handled in the same manner as an invalidated package on REBIND and in an autobind situation.

Tip: FL 504 This enhancement primarily introduces infrastructure to support a new capability that becomes available after you activate function level 504 or higher in Db2 13. For more information see Enabling autobind phase-in for packages invalidated at the statement level.

The new dependencies recorded are only for statement-level object dependencies. Only changes to an object invalidate a package at the statement level. Any changes in authorization privileges still invalidate a package at the package level. For more information, see Changes that invalidate packages.

Note: At function level 502 or higher, a package that is bound with DEPLEVEL(STATEMENT) option can be marked with VALID='S' if it is invalidated by a DROP FUNCTION statement. However, after the PTF for APAR PH55497 is applied, Db2 always marks a package that is invalidated by a DROP FUNCTION statement with VALID='N', regardless of the DEPLEVEL bind option for the package.

Package dependencies continue to be stored in the SYSPACKDEP catalog table. If a package is bound with the DEPLEVEL(STATEMENT) option, a new catalog table, SYSPACKSTMTDEP, stores the dependencies between a package statement and the objects referenced by that statement. The SYSPACKSTMTDEP catalog table contains the statement-level dependencies for a current package and all of the package copies.

Incompatible change:

An existing application might be marked with a value of 'S' in the VALID column of the SYSPACKAGE or SYSPACKCOPY table to indicate that the package has individual statements marked as invalid. There are no behavioral differences between how an invalidated package (VALID = 'N') and a partially invalidated package (VALID = 'S') are handled. The VALID value is reset to 'Y' in the same manner. However, if there are jobs or queries that look explicitly for 'N' in this column, these jobs might need to be modified to account for the new value of 'S'.

For more information, see Incompatible changes in Db2 13.

For more information, see the following related topics:

PH47560 delivered the functional code to record dependencies and validity for a package at the statement level.

V13R1M502 application compatibility

Most new SQL capabilities become available only to applications that use the equivalent application compatibility (APPLCOMPAT) level or higher. For a list, see SQL changes in Db2 13.

For more information about application compatibility levels, see Controlling the Db2 application compatibility level.

How to activate function level 502

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.

Procedure

To activate function level 502, 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 that 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 IPSTART 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 ===> V13R1M502. 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. Ensure that no incompatible applications will interfere with the catalog update. For details, see Identifying applications that are incompatible with catalog updates.
  4. Update the catalog and verify the changes for function level 502 by completing the following steps:
    1. Run the tailored DSNTIJTC job, or run the CATMAINT utility with LEVEL V13R1M502, 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.
    2. Run the generated DSNTIJX2 job to run the CHECK INDEX utility for Db2 catalog and directory indexes for new objects created in Db2 13.
  5. Check that Db2 is ready for function level activation by issuing the following ACTIVATE command with the TEST option:
    -ACTIVATE FUNCTION LEVEL (V13R1M502) TEST
    Db2 issues message DSNU757I to indicate the results. For more information, see Testing Db2 function level activation.
  6. Run the tailored DSNTIJAF job, or issue the following ACTIVATE command:
    -ACTIVATE FUNCTION LEVEL (V13R1M502)
  7. If you are ready for applications to use new capabilities in this function level, rebind them at the corresponding application compatibility level. For more information, see Controlling the Db2 application compatibility level.
    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.