Incompatible changes for Db2 13 migration or function level activation

When a statement-level invalidation occurs for a package that is bound with the DEPLEVEL(STATEMENT) option, the SYSPACKAGE.VALID column for the statement is marked with the value of 'S'. Statements in the package can be executed concurrently with autobind phase-in process, and any invalid statements go through incremental bind. If incremental binds fail due to prior invalidating changes to dependent objects, applications that previously failed with SQL code -904 might start receiving different SQL codes. For example, an incremental bind for a statement that depended on a dropped table might return -204 to the application.

Review the negative SQL codes in the application and take the appropriate actions as usual.

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'.

If you have jobs or queries that explicitly look for a value of 'N' in the VALID column of the SYSPACKAGE or SYSPACKCOPY catalog table, modify those jobs and queries to take into account the value of 'S', which indicates that statements within the package are invalid and the package needs to be rebound.

Migration-related automatic binds (also called autobinds) occur in Db2 13 because it cannot use runtime structures from a plan or package that was last bound in a release earlier than Db2 11. Plans and packages that were bound in Db2 12 can run in Db2 13, without the risk of migration-related autobinds. However, plans and packages that are bound in Db2 13 cannot run on Db2 12 members without an autobind in Db2 12.

If you specify YES or COEXIST for the ABIND subsystem parameter, Db2 13 automatically rebinds plans and packages that were bound before Db2 11 when Db2 executes the packages.

If you specify NO for the ABIND subsystem parameter, negative SQLCODEs are returned for each attempt to run a package or plan that was bound before Db2 11. SQLCODE -908, SQLSTATE 23510 is returned for packages, and SQLCODE -923, SQLSTATE 57015 is returned for plans until they are rebound in Db2 13.

Rebind all packages that were last bound before Db2 11 in Db2 12, before you migrate to Db2 13. This action is required for any packages run in the last 18 months, before you can migrate to Db2 13. For more information, see Activate function level 510 in Db2 12.

For more information about the impacts that migration-related automatic rebinds can have in your Db2 environment and actions that you can take to avoid them, see Rebind old plans and packages in Db2 12 to avoid disruptive autobinds in Db2 13.

Starting in Db2 12 or later with the PTF applied for APAR PH50729, Db2 resets IFCID 402 statistics counters immediately if the warning or exception threshold for the associated profile changes when you issue a START PROFILE command.

In Db2 12, the new behavior is used only if the RESET_IFCID402 option is specified for the DDF_COMPATIBILITY subsystem parameter, which is removed in Db2 13.

If the new behavior was used in Db2 12, or Db2 13 is installed with the PTF for APAR PH50729 applied, Db2 13 always uses the new behavior.

1. Update any applications that use IFCID 402 counters to expect the new reset behavior.
2. Resubmit your customized copy of DSNTIJUZ.
3. Issue a SET SYSPARM command, or stop and restart Db2.

Db2 13 enforces use of the default setting for several removed subsystem parameters. For the list of these subsystem parameters, see Subsystem parameter changes in Db2 13.

A Db2 12 environment that uses a different setting than is enforced in Db2 13 might encounter problems at a migration, especially in Db2 data sharing coexistence, where some members run on Db2 12 while others are already migrated to Db2 13.

1. Review the list new or changed subsystem parameters, and especially the settings enforced by Db2 13 for removed subsystem parameters.
2. If your Db2 12 environment uses different settings, evaluate the potential impact of the new setting to your environment, and make any necessary changes.
3. Ensure that your subsystem parameters module runs with the new settings before migrating to Db2 13.

Db2 13 always operates as if this subsystem parameter setting is null.

Starting in Db2 12 or later with the PTF applied for APAR PH44833, The MAX_UDF subsystem parameter controls the maximum number of user-defined external scalar functions that can run concurrently in a Db2 thread. The maximum value of MAX_UDF is 99999. Before the introduction of MAX_UDF, the maximum number of user-defined external scalar functions that could run concurrently in a Db2 thread was unlimited.