There are a number of registry variables that are discontinued in Version 10.1. You should remove all references to them.
Registry or environment variable | Details |
---|---|
DB2_ASYNC_IO_MAXFILOP | This variable is obsolete because of the shared file handle table maintained by the threaded database manager. |
DB2_BAR_AUTONOMIC_DISABLE | This variable was needed for IBM internal use only. |
DB2COUNTRY | This variable is replaced with the DB2TERRITORY registry variable. Use the DB2TERRITORY registry variable to specify the region or territory code of a client application, which influences the date and time formats. DB2TERRITORY accepts the same values as DB2COUNTRY: for example, setting DB2COUNTRY to 68 is equivalent to setting DB2TERRITORY to 68. |
DB2DEFPREP | This variable was needed only when using old versions of DB2® where the DEFERRED_PREPARE precompile parameter was not available. |
DB2_DJ_COMM | This variable was used to specify the wrapper libraries that are loaded when the database manager is started. The wrapper library structure and loading method have since been enhanced making this variable obsolete. |
DB2DMNBCKCTLR | This variable is no longer necessary because back up domain controllers in the Active Directory are only on the Windows NT operating systems, not on the Windows 2003 and Windows XP Professional operating systems. DB2 Version 9.5 or later releases do not support the Windows NT operating systems. |
DB2FFDC | This variable is replaced with the DB2FODC registry variable. The same functionality that DB2FFDC provided is available if you use the DUMPCORE parameter of DB2FODC. By default, the DUMPCORE parameter is set to ON to enable core file generation and to maintain compatibility with previous releases. |
DB2_HASH_JOIN | This variable, created to provide control over the join method called hash join, is no longer necessary. The query optimizer automatically determines the best join method including hash join. |
DB2_MAP_XML_AS_CLOB_FOR_DLC | This variable is discontinued because most existing DB2 applications that access XML values do so with an XML-capable client (Version 9.1 and newer). You need this variable only for previous applications that generically fetched table data and could not parse UTF-8 XML data in a BLOB. |
DB2MEMMAXFREE | This variable is no longer necessary because the database manager now uses a threaded engine model. For more information, see The DB2 Process Model. |
DB2_QP_BYPASS_APPLICATIONS | This variable is no longer supported because the functionality provided by the DB2 Query Patroller has been replaced by the DB2 workload manager. |
DB2_QP_BYPASS_COST | This variable is no longer supported because DB2 Query Patroller is discontinued. The DB2 workload manager feature replaces DB2 Query Patroller and provides a complete solution. |
DB2_QP_BYPASS_USERS | This variable is no longer supported because DB2 Query Patroller is discontinued. The DB2 workload manager feature replaces DB2 Query Patroller and provides a complete solution. |
DB2ROUTINE_DEBUG | This variable is no longer necessary because this stored procedure debugger has been replaced by the unified debugger. |
DB2_RR_TO_RS | This variable is discontinued because Type-1 indexes are no longer supported. |
DB2_SNAPSHOT_NOAUTH | This variable is not needed because you can achieve the same functionality by using the SYSMON authority group. |
DB2_UPDATE_PART_KEY | This variable is obsolete because partitioning key updates are permitted by default. |
DB2_USE_DB2JCCT2_JROUTINE | This variable is no longer needed because the driver it relates to has been discontinued. |
DB2_VENDOR_INI | This variable is no longer necessary because you can put the environment variable settings that it contains into the file specified by the DB2_DJ_INI variable. |
DB2YIELD | This variable was only used on Windows 3.1, which is not supported by newer versions of DB2 |
Query Patroller registry variables:
|
These variables are no longer supported because DB2 Query Patroller is discontinued. DB2 workload manager feature replaces DB2 Query Patroller and provides a more complete solution. |
Remove the use of registry variables that are discontinued as they do not have the intended effect. If a replacement registry variable is indicated in Table 1, set it to the proper value to maintain wanted database manager behavior.