Application and SQL release incompatibilities
When you migrate to or apply maintenance in Db2 12, be aware of and plan for application and SQL release incompatibilities that might affect your Db2 environment.
The following incompatible changes apply at any Db2 12 function level, including when you first migrate to Db2 12. For incompatible changes that might impact your Db2 12 environment when you activate function levels 501 and higher, see Incompatible changes summary for function levels 501 and higher.
- SQL capabilities
- New SQL capabilities become available after the activation of the function level that introduces them or higher, for applications that run at the equivalent application compatibility level or higher. New SQL capabilities in the initial Db2 12 release become available in function level 500 for applications that run at the equivalent application compatibility level or higher. You can continue to run SQL statements compatibly with lower function levels, or previous Db2 releases, including Db2 11 and DB2® 10. For details, see Application compatibility levels in Db2 12
SUBSTR built-in function always returns an error message for invalid input
Previously, during execution of the SUBSTR built-in function, Db2 sometimes incorrectly returned a result for invalid input instead of issuing an appropriate error message. After the PTF for APAR PH36071 is applied and Db2 12 function level 500 or higher is activated, the SUBSTR_COMPATIBILITY subsystem parameter is set to PREVIOUS by default and Db2 continues to behave as before the PTF was applied. If the SUBSTR_COMPATIBILITY subsystem parameter is set to CURRENT, Db2 always enforces the rules for the SUBSTR built-in function that are documented in the SQL Reference and returns an SQL error code if the rules are not met.
SELECT SUBSTR('ABCD', 2+1, 3) FROM SYSIBM.SYSDUMMY1;'CD '.Before you set the SUBSTR_COMPATIBILITY subsystem parameter to CURRENT, you might need to modify some of your applications to handle this change.
Actions to take
In Db2 12, before you set the SUBSTR_COMPATIBILITY subsystem parameter to CURRENT, identify applications that are incompatible with this change by starting a trace for IFCID 0376 and then running the applications. Review the trace output for incompatible changes with the identifier 14. Correct affected applications so that they will be compatible if the SUBSTR_COMPATIBILITY subsystem parameter is set to CURRENT in the future.
CREATE TABLESPACE and CREATE INDEX statements with no space-level USING clause fail if the storage group specified when the containing database was created does not exist
Starting in Db2 12 at function level 500, Db2 records the default storage group for a table space or index in the Db2 catalog. However, Db2 also does not validate the existence of a storage group specified in the STOGROUP clause of a CREATE DATABASE statement. As a result, a CREATE TABLESPACE or CREATE INDEX statement that omits the USING clause at the table space or index level now fails with SQLCODE -204, if the storage group specified when the containing database was created does not exist.
Actions to take
- Specify a USING clause at the table space or index level in any CREATE TABLESPACE or CREATE INDEX statement that creates a table space or index in that database.
- Issue an ALTER DATABASE statement and specify STOGROUP clause that identifies a storage group that exists.
New maximum number of parameter markers or host variables in a single SQL statement
Db2 12 enforces the maximum number of parameter markers or host variables in a single SQL statement. Starting in function level 100, Db2 12 issues SQLCODE -101 for any SQL statement that contains more than 16,000 parameter markers or host variables.
Actions to take
Identify and modify any existing SQL statement that contains more than 16,000 parameter markers or host variables.
Result change for SQL statement EXPLAIN PACKAGE
When Db2 processes the SQL statement EXPLAIN PACKAGE, the HINT_USED column in the PLAN_TABLE is populated with EXPLAIN PACKAGE: copy. The copy field in the HINT_USED column will be one of the following values:
- "CURRENT" - the current copy
- "PREVIOUS" - the previous copy
- "ORIGINAL" - the original copy
This change supports the new rebind phase-in capability that is introduced by function level 505. However, the change takes effect immediately when you migrate to Db2 12.
Actions to take
Change the expected output for queries that reference this column.
Result change for SQL statement EXPLAIN STABILIZED DYNAMIC QUERY
When Db2 processes the SQL statement EXPLAIN STABILIZED DYNAMIC QUERY, the HINT_USED column in the PLAN_TABLE is populated with EXPLAIN PACKAGE: copy. The copy field in the HINT_USED column will be one of the following values:
- "CURRENT" - the current copy
- "INVALID" - the invalid copy
This change supports the new rebind phase-in capability that is introduced by function level 505. However, the change takes effect immediately when you migrate to Db2 12.
Actions to take
Change the expected output for queries that reference this column.
SYSCOPY catalog table DSVOLSER column changes
Db2 12 introduces a new capability to delete only FlashCopy image copies if equivalent sequential image copies exist, for an efficient backup procedure that uses minimal disk space. In support of this capability, the possible values for the DSVOLSER column in the SYSIBM.SYSCOPY catalog table have changed. Previously, the DSVOLSER column value was an empty string for cataloged, sequential, full image copies. Some applications might assume that if the length attribute of the DSVOLSER value is zero, the image copy is cataloged. In Db2 12, that assumption is no longer correct. For cataloged, sequential, full image copies that are created from a FlashCopy image copy with consistency, and also had uncommitted units of work backed out, the DSVOLSER column now contains Db2 checkpoint information.
For more information about this new capability, see Ability to delete only FlashCopy image copies.
Actions to take
Modify any applications that use the DSVOLSER column in the SYSCOPY catalog table to tolerate the checkpoint information for cataloged, sequential, full image copies. For details, see the description of DSVOLSER in SYSCOPY catalog table.
Application compatibility levels apply to data definition and data control statements
After the activation of function level 500 or higher in Db2 12, application compatibility levels also control syntax, semantics, default values, and option validation for most data definition statements and data control statements. Data definition statements (sometimes abbreviated as DDL) include various CREATE and ALTER statements. Data control statements (sometimes abbreviated as DCL) include various GRANT and REVOKE statements. Only application compatibility levels V12R1M509 and higher control the behavior of any data definition or data control statements.
The APPLCOMPAT bind option for a package applies to most static SQL data definition and data control statements. The CURRENT APPLICATION COMPATIBILITY special register applies to most dynamic SQL data definition and data control statements.
For implicit regeneration of an object, the application compatibility level that was in effect for the previous CREATE or ALTER statement for that object is used.
For materialization of pending data definition changes, the application compatibility level of the pending ALTER statement is used.
You can specify the USING APPLICATION COMPATIBILITY clause of certain ALTER statements to regenerate an object with a specific application compatibility level.
Automatic rebind of plans and packages created before DB2 10
Migration-related automatic binds (also called autobinds
) occur in Db2 12 because it cannot use runtime structures from a plan or package that was last bound in a release earlier than DB2 10. Plans and packages that were bound in Db2 11 can run in Db2 12, without the risk of migration-related autobinds. However, plans and packages that are bound in Db2 12 cannot run on Db2 11 members without an autobind in Db2 11.
If you specify YES or COEXIST for the ABIND subsystem parameter, Db2 12 automatically rebinds plans and packages that were bound before DB2 10 when Db2 executes the packages. The result of the automatic bind creates a new package and discards the current copy. Db2 does not move the current copy to the previous or original copy because Db2 12 cannot use it. If a regression occurs, REBIND SWITCH PREVIOUS and REBIND SWITCH ORIGINAL are not available.
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 10. SQLCODE -908, SQLSTATE 23510 is returned for packages, and SQLCODE -923, SQLSTATE 57015 is returned for plans until they are rebound in Db2 12.
Actions to take
By preparing for migration to Db2 12 in Db2 11, you can reduce the change and risk for packages that are subject to automatic binds in Db2 12. To do that, you rebind all packages that were last bound before DB2 10 in Db2 11, before you migrate to 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 11 to avoid disruptive autobinds in Db2 12.
KEEPDYNAMIC(YES) bind option support for ROLLBACK
In Db2 12, when the APPLCOMPAT value is V12R1M500, the KEEPDYNAMIC(YES) bind option affects both COMMIT and ROLLBACK statements. With KEEPDYNAMIC(YES), the dynamic SQL statements in the package are retained after COMMIT or ROLLBACK, and those statements can run again without another PREPARE.
Prior to Db2 12, the KEEPDYNAMIC(YES) bind option applied only to COMMIT statements. After a ROLLBACK statement, another PREPARE was required so that the dynamic SQL statements could run. This situation is also true in Db2 12 if application compatibility is set to V11R1 or earlier.
In Db2 12, when the APPLCOMPAT value is V12R1M500 or higher, after a ROLLBACK statement is issued, the behavior is different than in prior versions:
- An OPEN statement without a preceding PREPARE statement does not receive an SQLCODE -514.
- An EXECUTE statement without a preceding PREPARE statement does not receive an SQLCODE -518.
An application that was written in Db2 11 and that was bound with KEEPDYNAMIC(YES) was required to prepare dynamic SQL statement again after a ROLLBACK was issued. In Db2 12 when application compatibility is set to V12R1M500 or higher, those extra PREPARE statements are unnecessary.
Actions to take
As you migrate to Db2 12, review packages that use the KEEPDYNAMIC(YES) bind option. You can make dynamic SQL programs that are bound with KEEPDYNAMIC(YES) run more efficiently by removing PREPARE statements that prepare SQL statements again, following execution of ROLLBACK statements. Do not take this action until you are sure that you no longer need to run the programs in Db2 11 or earlier. After migrating to Db2 12, if you take this action (to remove PREPARE statements after ROLLBACK), programs will not work properly if you subsequently set application compatibility to V11R1 or earlier.
Alterations to index compression are pending changes for universal table spaces
When the application compatibility level is V12R1M500 or higher, altering to use index compression for indexes in universal table spaces is a pending change that places the index in advisory REORG-pending (AREOR) status. The LOAD REPLACE and REBUILD INDEX utilities no longer materialize the change. You must use an online REORG to materialize the new value for the COMPRESS attribute in the ALTER INDEX statement.
In releases before Db2 12, any alteration to use index compression placed the index in REBUILD-pending (RBDP) status. You needed to use the REBUILD INDEX utility to rebuild the index, or use the REORG utility to reorganize the table space that corresponds to the index.
Actions to take
For indexes in universal table spaces, use an online REORG to materialize the new value for the COMPRESS attribute in the ALTER INDEX statement.
Data types of output arguments from a stored procedure call in a Java application
In function level 500 or higher with application compatibility set to V11R1, when a Java™ application that uses the IBM® Data Server Driver for JDBC and SQLJ calls a stored procedure, the data types of stored procedure output arguments match the data types of the parameters in the stored procedure definition.
Explanation
Before DB2 10, if a Java client called a Db2 for z/OS® stored procedure, the data types of output arguments matched the data types of the corresponding CALL statement arguments. Starting in DB2 10, the data types of the output arguments match the data types of the parameters in the stored procedure definition.
In Db2 12, when application compatibility is set to V10R1, you can set the DDF_COMPATIBILITY subsystem parameter to SP_PARMS_JV to keep the behavior that existed before DB2 10. However, when application compatibility is set to V11R1 or V12R1M100, or to V12R1M500 or higher, SP_PARMS_JV is no longer supported.
In Db2 12 with application compatibility set to V11R1 or V12R1M100, or to V12R1M500 or higher, if the version of the IBM Data Server Driver for JDBC and SQLJ is lower than 3.63 or 4.13, a java.lang.ClassCastException might be thrown when an output argument value is retrieved.
Actions to take
Take one of the following actions:
- Upgrade the IBM Data Server Driver for JDBC and SQLJ to version 3.63 or 4.13, or later.
- Modify the data types in CallableStatement.registerOutParameter method calls to match the parameter data types in the stored procedure definitions. You can set application compatibility to V10R1 and run a trace for IFCID 0376 to identify affected applications. Trace records for those applications have a QW0376FN field value of 8.
SELECT INTO statements with UNION or UNION ALL
A UNION or UNION ALL is not allowed in the outermost from-clause of a SELECT INTO statement. However, releases before Db2 12 inadvertently tolerate SQL statements that contain this invalid syntax.
The behavior is controlled by the DISALLOW_SEL_INTO_UNION subsystem parameter. In Db2 11, the default setting tolerates the invalid syntax. In Db2 12 the default setting disallows the invalid syntax.
An application that uses the invalid SQL syntax fails at BIND or REBIND with SQLCODE -109.
Actions to take
Identify any packages that use UNION or UNION ALL in the from-clause of a SELECT INTO statement and correct them as necessary. You can temporarily specify that Db2 continues to tolerate the invalid syntax NO for the DISALLOW_SEL_INTO_UNION subsystem parameter. However, this subsystem parameter is deprecated and expected to be removed in the future.
You can identify affected packages while DISALLOW_SEL_INTO_UNION is set to NO by binding suspected packages into a dummy collection ID with EXPLAIN(ONLY) and monitoring IFCID 0376 records. Trace records for the affected applications have a QW0376FN field value of 11.
Use the following procedure:
- Issue the following SQL statement to generate a list of BIND commands.
SELECT 'BIND PACKAGE(DUMMYCOL) COPY(' || COLLID || '.' || NAME || ') ' || CASE WHEN(VERSION <> '') THEN 'COPYVER(' || VERSION || ') ' ELSE '' END || 'EXPLAIN(ONLY)' FROM SYSIBM.SYSPACKSTMT WHERE STATEMENT LIKE '%SELECT%INTO%UNION%' OR STATEMENT LIKE '%SELECT%UNION%INTO%';The statement generates output similar to the following BIND subcommand:
BIND PACKAGE(DUMMYCOL) COPY(DSN_DEFAULT_COLLID_PLAY01.PLAY01) EXPLAIN(ONLY) - Copy the results of the SELECT statement into a bind job. If any BIND subcommands are longer than 72 bytes, formatting is required.
- Start and collect a trace for IFCID 0376.
- Run the bind job that you created.
- Stop the IFCID 0376 trace and analyze the output.
Change in SQLCODE when the POWER built-in function result is out of range
After the activation of function level 500 or higher in Db2 12, the SQLCODE that is returned when the result of the POWER® built-in function is out of range is changed in some cases.
For example, the following query returns SQLCODE +802:
SELECT POWER(DOUBLE(2.0E38), DOUBLE(2.0))
FROM SYSIBM.SYSDUMMY1; Invocations of the POWER function that have DOUBLE arguments and return out-of-range results return SQLCODE +802 instead of SQLCODE -802.
Actions to take
In Db2 12, before function level 500 or higher is activated, identify applications with this incompatibility by starting a trace for IFCID 0376, and then running the applications. Review the trace output for incompatible changes with the identifier 1201. Adjust error processing to account for the change in the returned SQLCODE from an error to a warning.
CHAR9 and VARCHAR9 functions for compatibility with pre-DB2 10 string formatting of decimal data
DB2 10 changed the formatting of decimal data by the CHAR and VARCHAR built-in functions and CAST specifications with a CHAR or VARCHAR result type. In Db2 12 you can use alternative functions for compatibility with applications that require decimal to string output in the pre-DB2 10 formats:
Actions to take
Review your setting for the BIF_COMPATIBILITY subsystem parameter. If the value is not CURRENT, and you have applications that require decimal to string output in the pre-DB2 10 format, you can rewrite SQL statements to use the CHAR9 and VARCHAR9 functions instead. This approach enables the development of new applications that can accept the current string formatting of decimal data.
To modify your applications to take advantage of the CHAR9, VARCHAR9 functions:
- Use an IFCID 0376 trace to identify applications that depend on the pre-DB2 10 formats.
- Rewrite the SQL statements in the identified applications to use the CHAR9 and VARCHAR9 functions instead of the CHAR and VARCHAR functions.
- Set the BIF_COMPATIBILITY value to CURRENT.
Subsystem parameter BIF_COMPATIBILITY and SQL schemas for compatibility with pre-DB2 10 string formatting of decimal data
DB2 10 changed the formatting of decimal data by the CHAR and VARCHAR built-in functions and CAST specifications with a CHAR or VARCHAR result type. You can temporarily override these changes on a subsystem level by setting the BIF_COMPATIBILITY subsystem parameter to one of the pre-DB2 10 settings. You can also temporarily override these changes on an application level by adding schema SYSCOMPAT_V9 to the front of the PATH bind option or CURRENT PATH special register. The latter approach works for CHAR and VARCHAR functions and does not affect CAST specifications.
The recommended approach is to modify your applications to handle the DB2 10 and later behavior for these functions, as described in the following steps.
Actions to take
To modify your applications to handle the DB2 10 and later behavior for CHAR, VARCHAR, and CAST:
- Identify applications that need to be modified to handle this change. Run a trace for IFCID 0376 to identify affected applications.
- Ensure that the BIF_COMPATIBILITY subsystem parameter is set to V9_DECIMAL_VARCHAR.
To handle the change for the CHAR function only, you can set BIF_COMPATIBILITY to V9, and complete the following steps for the CHAR function.
- Change any affected applications to handle the DB2 10 and later CHAR and VARCHAR behavior, including stored procedures, non-inline user-defined functions, and trigger packages. Rewrite affected CAST specifications with the appropriate CHAR or VARCHAR function and a CAST to the correct length if needed.
- Rebind and prepare packages with the PATH(SYSCURRENT,SYSIBM) rebind option. Putting the SYSCURRENT schema at the beginning of the SQL path causes the DB2 10 and later behavior to be used for the CHAR and VARCHAR built-in functions.
Repeat this step for native stored procedures (SQLPL) and non-inline SQL scalar functions.
- For views that reference these casts or built-in functions, determine whether the view needs to be changed to have the expected output. Drop and re-create the views with the PATH(SYSCURRENT,SYSIBM) rebind option only if necessary. Rebind any applications that reference the views with the PATH(SYSCURRENT,SYSIBM) option to use the DB2 10 and later CHAR and VARCHAR built-in functions. Repeat this step for inline SQL scalar functions.
- For materialized query tables or indexes on expressions that reference these casts or built-in functions, drop and re-create the materialized query tables or indexes on expressions with the PATH(SYSCURRENT,SYSIBM) rebind option. Issue the REFRESH TABLE statement for materialized query tables. Rebind any applications that reference the materialized query tables or indexes on expressions with the PATH(SYSCURRENT,SYSIBM) option to use the DB2 10 and later CHAR and VARCHAR built-in functions.
- Change the value of the BIF_COMPATIBILITY subsystem parameter to CURRENT. When the subsystem parameter value is CURRENT, new applications, rebinds, and CREATE statements use the DB2 10 and later CHAR, VARCHAR, and CAST behavior.
Materialized query tables and expression-based indexes use the CHAR, VARCHAR, and CAST behavior that is specified during its creation. If a reference statement has a different behavior that is specified by the BIF_COMPATIBILITY parameter or a different path, the materialized query table or expression-based index is not used.
EBCDIC mixed string input to the RTRIM, TRIM, LTRIM, and STRIP built-in functions must be valid
Starting at application compatibility level V12R1M500 or higher, Db2 12 applies more validation checking for EBCDIC mixed-string input to the RTRIM, TRIM, LTRIM, and STRIP built-in functions.
Generally, Db2 has required valid EBCDIC mixed-string data for input to these functions since version 10, but Db2 12 now detects more cases than earlier releases.
With the new validation checking, when Db2 12 performs a trim operation, and the string-expression argument of the RTRIM, TRIM, LTRIM, or STRIP built-in function contains invalid EBCDIC mixed data, Db2 issues SQLCODE -171.
Actions to take
Check whether EBCDIC mixed data that is specified for the string-expression argument of an RTRIM, TRIM, LTRIM, or STRIP built-in function is valid, and resolve the invalid data.
In valid mixed data, the double-byte portions of the input strings begin with X'0E' (shift-out character), end with X'0F' (shift-in character), and have an even number of bytes between the X'0E' and X'0F' characters. Data that does not meet these criteria is invalid mixed data. When invalid mixed data is specified for the string-expression argument of an RTRIM, TRIM, LTRIM, or STRIP built-in function, SQLCODE -171 is returned in some cases. If Db2 trims the specified characters before it reaches an invalid portion of a mixed string, the trim operation is successful.
Setting an application compatibility of V12R1M100 or lower (if PTF for APAR PH25783 is applied) might avoid the error while you resolve the invalid data. At the lower application compatibility levels, Db2 12 attempts to tolerate the invalid mixed data identified by the new validation checking, and it allows the trim operation to complete if possible. However, if Db2 is still unable to perform the trim operation, SQLCODE -171 is issued.
Maximum number of user-defined external scalar functions running in a Db2 thread is no longer unlimited (APAR PH44833)
Starting at application compatibility level V12R1M100 (if the PTF for APAR PH44833 is applied), Db2 12 introduces the MAX_UDF subsystem parameter. MAX_UDF 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.
Actions to take
If an application contains SQL statements that invoke user-defined external scalar functions, and one of those SQL statements is rejected with SQLCODE -904 and reason code 00E70082, increase the MAX_UDF subsystem parameter value, or change the application to run fewer functions concurrently in a Db2 thread.
SQL reserved words
Db2 12 introduces several new SQL reserved words, which are listed in Reserved words in Db2 for z/OS.
In some cases, the use of these reserved words might cause an incompatibility before new function is activated in Db2 12 , regardless of the setting of the APPLCOMPAT flag.
Actions to take
Collect IFCID 0376 trace records in Db2 11. Values 4, 5, and 6 for the QW0376FN field indicate instances of reserved words in applications that will cause an incompatibility in Db2 12. Adjust these applications by changing the reserved word to a delimited identifier or by using a word that is not reserved in Db2 12.
Built-in function and existing user-defined functions
For built-in and user-defined functions the combination of the function name and the parameter list form the signature that Db2 uses to identify the function. If the signatures of new or changed built-in functions in Db2 12 match the signatures existing user-defined functions, applications with unqualified references to the existing user-defined functions might start invoking the new or changed built-in functions instead of the user-defined functions. Db2 12 introduces the following built-in function changes:
Db2 12 introduces or changes the following built-in functions.
| APPLCOMPAT level | Function name | Change introduced | Incompatible change? |
|---|---|---|---|
| V12R1M507 | Various | The following functions are newly supported in Db2 for z/OS as passthrough-only expressions, which are passed through to IBM Db2 Analytics Accelerator for z/OS.
|
No |
| V12R1M506 | HASH | New built-in function. | No |
| V12R1M506 | CHARACTER_LENGTH or CHAR_LENGTH | CHAR_LENGTH is now supported as an alternative function name. | No |
| V12R1M506 | CLOB | TO_CLOB is now supported as an alternative function name. | No |
| V12R1M506 | COVAR_POP or COVARIANCE or COVAR | COVAR_POP is now supported as an alternative function name. | No |
| V12R1M506 | LEFT | STRLEFT is now supported as an alternative function name. | No |
| V12R1M506 | POWER or POW | POW is now supported as an alternative function name. | No |
| V12R1M506 | POSSTR | STRPOS is now supported as an alternative function name. | No |
| V12R1M506 | RANDOM or RAND | RANDOM is now supported as an alternative function name. | No |
| V12R1M506 | RIGHT | STRRIGHT is now supported as an alternative function name. | No |
| V12R1M506 | TIMESTAMP_FORMAT | TO_TIMESTAMP is now supported as an alternative function name. | No |
| V12R1M505 | DECRYPT_DATAKEY_INTEGER, DECRYPT_DATAKEY_BIGINT, DECRYPT_DATAKEY_DECIMAL, DECRYPT_DATAKEY_VARCHAR, DECRYPT_DATAKEY_CLOB, DECRYPT_DATAKEY_VARGRAPHIC, DECRYPT_DATAKEY_DBCLOB, and DECRYPT_DATAKEY_BIT | New built-in functions. | No |
| V12R1M505 | ENCRYPT_DATAKEY | New built-in function. | No |
| V12R1M504 | Various | The following functions are newly supported in Db2 for z/OS as passthrough-only expressions, which are passed through to IBM Db2 Analytics Accelerator for z/OS. | No |
| V12R1M502 | GRAPHIC | The first argument now accepts numeric data types, including SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, FLOAT, and DECFLOAT. | No |
| V12R1M502 | VARGRAPHIC | The first argument accepts numeric data types, including SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, FLOAT, and DECFLOAT. | No |
| V12R1M501 | LISTAGG | New built-in function. | No |
| V12R1M500 | ARRAY_AGG | Newly supported built-in function when used for associative array aggregation. | No |
| V12R1M500 | GENERATE_UNIQUE_BINARY | New built-in function. | No |
| V12R1M500 | HASH_CRC32, HASH_MD5, HASH_SHA1, and HASH_SHA256 | New built-in functions. | No |
| V12R1M500 | LOWER | The following locales can now be specified:
|
|
| V12R1M500 | PERCENTILE_CONT | New built-in function. | No |
| V12R1M500 | PERCENTILE_DISC | New built-in function. | No |
| V12R1M500 | TRANSLATE | The following locales can now be specified:
|
No |
| V12R1M500 | UPPER | The following locales can now be specified:
|
No |
| V12R1M500 | WRAP | New built-in function. | No |
| V12R1M100 | BLOCKING_THREADS | New built-in function. |
Actions to take
To continue to execute a user-defined function with the same name or signature as a new built-in function or signature, qualify the name of the existing user defined function in your application. For more information about Db2 resolves qualified and unqualified references to functions, see Function resolution.
SQLCODE changes
Some SQLCODE numbers and message text might have changed in Db2 12. Also, the conditions under which some SQLCODEs are issued might have changed. For more information, see New, changed, and deleted codes.