DB2 Viper Release Candidate 1 Release Notes

About This Document

This document provides the known limitations/restrictions and late-breaking news of DB2^(R) Viper Release Candidate 1 . For information about DB2 Viper Release Candidate 1 , please refer to the Information Center: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp.

The above version of the DB2 Information Center may contain external links that point to information on the current generally available version of DB2, which is V8.2.

What's New?

The What's New section has been updated for DB2 Viper Release Candidate 1 to reflect the most current information available on significant changed, deprecated, and discontinued features. It can be found in the DB2 Information Center:

DB2 for Linux^(TM), UNIX^(R) and Windows^(R): Product overviews->Database systems

DB2 Connect^(TM): Product overviews->Mainframe and mid-range server access

Only English is supported in this release candidate.

Installation Instructions

If you have previously installed DB2 Native XML Alpha, DB2 Viper Closed Beta or any of their refreshes, you must uninstall that product following the instructions in Appendix B or C accordingly before installing DB2 Viper Release Candidate 1. You must drop and re-create any database created with the alpha or beta version of DB2.

To download DB2 Viper Release Candidate 1, please go to the DB2 Viper download website: http://www-306.ibm.com/software/data/db2/udb/viper/index_download.html.

Linux and UNIX:

1. gunzip and untar the downloaded file.
2. cd <product>, where <product> can be ese, conee, rtcl, etc.
3. run "./db2setup" as root.
4. By default DB2 is installed under /opt/ibm/db2/V9.0 for Linux and /opt/IBM/db2/V9.0 for UNIX.

Windows:

1. unzip the downloaded file.
2. cd <product>\image, where <product> can be ese, conee, rtcl, etc.
3. run "setup.exe".

Detailed installation instructions are available in the DB2 Information Center under Installing.

The latest installation prerequisite information is available in Appendix A.

Known Limitations and Restrictions

Default Browser & Path

One of the following browsers is required to run the DB2 install launchpad (setup.exe) on Windows, and to run FirstSteps (db2fs) on Windows, Linux, and UNIX:

• Internet Explorer 5.0 and up
• Mozilla 1.4 and up
• Firefox 1.0 and up
• Netscape 7.0 and up

If you have unzipped the download file into a network path or a path with a space, the install launchpad might fail to open properly.

Symptom

An empty browser window appears after running setup.exe from a path similar to one of the following:

• \\server1\share1\ESE\image\setup.exe
• C:\Documents and Settings\username\Desktop\ESE\image\setup.exe

Workarounds

Do one of the following:

• Unzip the download file to a local directory which has no spaces in the path.
• Temporarily set your default browser to Internet Explorer while running setup.exe.

Performance

For performance-sensitive applications, particularly those involving heavy INSERT activity, the use of DMS FILE or DMS RAW tablespaces is strongly recommended. Furthermore, with the use of DMS FILE you are able to take advantage of autonomic capabilities in DB2 such as automatic storage.

Migration

• Instance and database migration is ready for testing in this release candidate, however, the databases created or migrated with this release candidate will not be supported in subsequent release candidates, or in the GA version.
• If you are migrating from a product other than DB2 Enterprise Server Edition Version 8, you may need to use the db2iupdt command to upgrade the node type of your instance after the installation has completed.
• On Windows EM64T, when upgrading a DB2 Viper 32-bit Copy to a 64-bit Copy, the 32-bit shortcuts will not be removed. You can remove these shortcuts manually.
• If you are using db2imigr.exe to migrate a version 8 instance you will need to re-configure any ODBC data sources to use the new DB2 copy specific ODBC driver.
• The DBM configuration parameter JDK_PATH is affected in the following ways in this release candidate.
  1. New DB2 Viper instance:

     The JDK_PATH will be set to the JDK under the DB2 Viper installation.

  2. Migration from DB2 V8.x instance to DB2 Viper instance:

     The JDK_PATH will be updated to point to the JDK under the DB2 Viper installation.

  3. Moving from one DB2 Viper instance to another DB2 Viper instance:

     The JDK_PATH will be updated to point to the DB2 Viper installation that the instance is moved to.

XML Schema Repository (XSR)

When registering an XML Schema in the database, a larger application heap (APPLHEAPSZ) may be required, depending on the size of the XML Schema. The recommended size is 1024, but larger schemas will require additional memory.

On Windows platform (32-bit), during COMPLETE XML SCHEMA or ALTER XSROBJECT ENABLE DECOMPOSITION when xml schema contains a long type derivation chain or a long chain of references, it may be necessary to increase DB2 agent stack size (default value 16), in order to avoid stack overflows (causing abormal termination).

 

db2start  

db2 update  dbm   cfg  using AGENT_STACK_SZ 300  

db2stop  

db2start  

Be aware that this will apply to ALL DB2 agent processes, which may impact memory usage on the server.

XML Extender

Users of the following XML Extender UDFs will not get correct results.   Instead of the transformed document being returned, the returned clob contains unprintable hex characters.  

The XSLT UDFs affected are:

• XSLTransformToClob( CLOB(2G), CLOB(2G), INTEGER)
• XSLTransformToClob( CLOB(2G), VARCHAR(256), INTEGER)
• XSLTransformToClob( CLOB(2G), CLOB(2G), CLOB(2G), INTEGER)
• XSLTransformToClob( CLOB(2G), VARCHAR(256), CLOB(2G), INTEGER)
• XSLTransformToClob( CLOB(2G), CLOB(2G), VARCHAR(256), INTEGER)
• XSLTransformToClob( CLOB(2G), VARCHAR(256), VARCHAR(256), INTEGER)

Self Tuning Memory

The keyword MANUAL on the ALTER BUFFERPOOL statement should not be used as it will be removed from the GA version of DB2 Viper.

DBPATHS Administrative View

The DBPATHS administrative view returns the values for database paths required for tasks such as split mirror backups. The following limitations apply to the administrative view when copying files to a secondary system:

1. No database can exist in the target directory in the secondary system.
2. The view output misses the information about the sqldbdir path. The user needs to copy this directory (located in <DBPATH>/<Node Number>) over from the primary to the secondary.
3. The view returns the path that was specifed during database creation (or database path by default) for the automatic storage path. The containers for these tablespaces actually reside in<storagePath>/<instance>/<nodenumber>/<databasename>. Therefore, the user only needs to copy over the files under <storagePath>/<instance>/<nodenumber>/<databasename> for the automatic storage tablespace containers rather than all the files under <storagePath>.

.NET Support

Only DB2 .NET Data Provider is supported in this release candidate.

Existing .NET applications need to be rebuilt as there is no redirection in place from DB2 V8.x to the DB2 Viper Release Candidate 1. No application changes are necessary, but the compile needs to reference the DB2 .NET Data Provider in sqllib/bin/netf11/IBM.Data.DB2.dll.

The DB2 Development Add-ins for Visual Studio .NET will be available for download in the future, and is not supported in this release candidate at this time.

CREATE DATABASE Command

DB2 Viper supports the use of node expressions as part of the database path for UNIX platforms only in this release candidate. Specifying a node expression for the database path on Windows systems will result in a SQL1052N error stating that an invalid path has been specified. Node expressions on Windows platforms will be supported in the GA version.

FirstSteps

The 'Create your own Database' button under the 'Database Creation' topic does not work to bring up the Create Database With Automatic Maintenance wizard in this release candidate.

DB2 Connect Enterprise Edition

Only typical installation is recommended.

Instance migration is not supported for installation of DB2 Connect Enterprise Edition on top of DB2 Enterprise Server Edition for this release candidate.

Configuration Advisor

The Configuration Advisor is not invoked by default if the database is created with a storage path in this release candidate. The workaround is to run the Configuration Advisor manually afterwards.

Fenced stored procedures

Symptom

1. CTE0100 A DB2 operation failed. DB2 information: "38503" "[IBM][CLI Driver][DB2/AIX64] SQL1131N DARI (Stored Procedure) process has been terminated abnormally. SQLSTATE=38503
2. exec(): 0509-036 Cannot load program db2fmp...

Problem

db2fmp fails to start. This problem is specific to AIX 5.3 ML 04.

Solution

Download and install the AIX ifix "rtlfix.060327.epkg.Z".

To download the ifix: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=db2v9rc1&S_PKG=1_db2ese

To install the ifix: emgr -e rtlfix.060327.epkg.Z

Data row compression

The Data row compression information provided in the What's New for Version 9 should be replaced with the following:

In DB2 Version 9.1, you can compress table data objects. DB2 uses a static dictionary-based lossless row compression method.

Compression saves valuable disk space, but it can also save I/O since more logical data can now fit per database page. It is possible that log space will be saved as well. Further, more logical data can be cached in the buffer pool, leading to quicker access times. The cost associated with compression is due to the extra CPU cycles needed to compress and decompress the data. Compression and decompression is done on a per-row basis, at row access time.

Large tables, which exhibit repetitive patterns will benefit from compression. Note that neither LOB nor LF nor XML objects will be compressed. Compression only applies to data objects.

When creating or altering table you can specify the ROW COMPRESS YES clause. Rows will not be compressed until a dictionary is created for the table data object(s). This may be done by either executing the REORG TABLE command, or by using the INSPECT ROWCOMPESTIMATE command. Note that the benefit of using the REORG command is that the existing rows in the table will be compressed. If the INSPECT ROWCOMPESTIMATE command is used, only rows touched subsequently will be compressed. Note that the ROW COMPRESS clause is compatible with the existing VALUE COMPRESS compression.

Trigger

Symptom: SQL0901N message

Message:

SQL0901N The SQL statement failed because of a non-severe system error. 
Subsequent SQL statements can be processed. 
(Reason "Can't reoptimize as section hasn't been compiled!".) 
SQLSTATE=58004

Scenario: A table has a trigger defined for it that uses a special register as part of the trigger action. After issuing an alter table, the first access to the table after the alter is done via a package that was bound with REOPT ALWAYS. This causes the regeneration of the trigger which results in the SQL0901N message. Work Around:

1. Manually drop and recreate the invalid trigger via CLP.
2. Ensure the first access to the altered table is via a package that was not bound with either REOPT ONCE or REOPT ALWAYS.

WebSphere^(R) Application Server V6.0.2.*

Using WebSphere Application Server starting 6.0.2.1, and prior to 6.0.2.8, running application with the legacy CLI-based JDBC type 2 driver will receive the following SQLException:

java.sql.SQLException: [IBM][JDBC Driver] CLI0626E getHoldability
is not supported.

The test for the support of holdability is failing due to changes in the exception returned by DB2. Classes have to be updated to understand that and return the correct result.

Refer to the following site for more information: http://www-1.ibm.com/support/docview.wss?uid=swg1PK18919

WebSphere Information Integrator - Q Replication

Avoiding cold starts of replication programs after DB2 migration

If the Q Capture or Capture program has not finished processing all log files in DB2 Version 8 before you migrate to DB2 Viper, changes in log file names during the migration can force you to perform a cold start of the Q Capture or Capture program after you have migrated.

All existing log files are renamed with a .mig extention. The format of DB2 Viper log files is different from log files in DB2 Version 8 and a Capture program that is running in DB2 Viper may not be able to access log files from DB2 Version 8 even if you rename the .mig files to .log.

To avoid a cold start, use the following procedure when you migrate to a new version of DB2:

1. Make sure that all applications complete their work against the instance's V8 databases before you begin migrating.
2. Make sure that all changes have been captured from the log by using one of the following methods:
   • Run Q Capture (asnqcap command) or Capture (asncap command) with the AUTOSTOP option to prompt the programs to read all changes up to the end of the log.
   • Check the monitor tables. For Q Capture check that ROWS_PROCESSED is 0 in the IBMQREP_CAPMON table. For Capture, check that TRANS_PROCESSED is 0 in the IBMSNAP_CAPMON table.
3. If you did not run Capture with AUTOSTOP, stop Q Capture or Capture using one of the following commands:

   Q Capture

   asnqccmd capture_server=database_name capture_schema=schema stop  

   Capture

   asnccmd capture_server=database_name capture_schema=schema stop 

   Make sure that Q Capture or Capture stop without errors. If errors occur, handle errors as appropriate and retry the stop command. Once you migrate to the new DB2 release, DB2 will not be able to read the old logs and return log records to the Capture or Q Capture program.
4. Migrate DB2.
5. Do one of the following:

   Q Capture:

   If it is guaranteed that Q Capture will be the first application to start on the newly migrated database, start Q Capture with the WARMNS and LSN options (WARMNS ensures that Capture will not switch to a COLD start):

   asnqcap capture_server=<database_name> capture_schema=schema startmode=WARMNS
        LSN=FFFF:FFFF:FFFF:FFFF:FFFF

   Otherwise, start Q Capture with the WARMNS and MIGRATE options:

   asnqcap capture_server=<database_name> capture_schema=schema startmode=WARMNS MIGRATE 

   Capture:

   Start Capture with the WARMNS and MIGRATE options.

   asncap capture_server=<database_name> capture_schema=schema startmode=WARMNS MIGRATE

Unsupported Features

The following features are not supported in this release candidate:

• Query Patroller is not supported.
• Spatial Extender is not supported.
• Response file generation via the DB2 Setup Wizard or db2rspgn is not supported.
• DB2 Thin Client and DB2 Thin Connect are not supported.
• The SQLJ.REFRESH_CLASSES stored procedure is not supported.

Appendix A. Installation Prerequisites

This DB2 release has specific limitations. In particular, a 64-bit operating system kernel is required for UNIX and Linux installations, except in the case of the Linux x86 platform. Please refer to the relevant section below for detailed information specific to each supported platform.

Installation Requirements for AIX

To install a DB2 product, the following operating system, hardware, and communications prerequisites must be met:

Software considerations

• Ensure that you are using the 64-bit operating system kernel. To switch to a 64-bit kernel, enter the following commands:

  ln -sf /usr/lib/boot/unix_64 /unix 
  ln -sf /usr/lib/boot/unix_64 /usr/lib/boot/unix 
  lslv -m hd5 
  bosboot -ad /dev/ipldevice 
  shutdown -Fr 
  

• DB2 Viper requires the "November 2005 IBM C++ Runtime Environment Components for AIX" (xlC.rte 8.0.0.0), which is available from: http://www-1.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&dc=D400&uid=swg24011029&loc=en_US&cs=utf-8&lang=en
• A browser is also required to view online help.

Installation Requirements for the Solaris Operating Environment

To install a DB2 server product, the following operating system, hardware, and communications prerequisites must be met:

Software considerations

• A browser is also required to view online help.

"Recommended & Security Patches" can be obtained from the http://sunsolve.sun.com Web site. From the SunSolve Online Web site, click on the "Patches" menu item in the left panel.

The Java^(TM) 2 Standard Edition (J2SE) Solaris Operating Environment Patch Clusters and the SUNWlibC software are also required and can be obtained from the http://sunsolve.sun.com Web site.

For DB2 on 64-bit Fujitsu PRIMEPOWER systems, you require the following:

• Solaris 9 Kernel Update Patch 112233-01 or later to get the fix for patch 912041-01.

The Fujitsu PRIMEPOWER patches for the Solaris Operating Environment can be downloaded from FTSI at: http://download.ftsi.fujitsu.com/.

Installation Requirements for Windows Operating Systems

To install a DB2 product, the following operating system, software, and hardware prerequisites must be met:

Additional software considerations

• MDAC 2.8 is required. The DB2 Setup wizard will install MDAC 2.8 if it is not already installed.
• A browser is required to view online help.

Windows 2000 Terminal Server installation limitation

You cannot install DB2 Viper from a network mapped drive using a remote session on Windows^(R) 2000 Terminal Server edition. The available workaround uses Universal Naming Convention (UNC) paths to launch the installation or run the installation from the console session.

For example, if the directory c:\pathA\pathB\...\ pathN on a serverA is shared as serverdir , you can open \\serverA\serverdir\setup.exe to access the file c:\pathA\pathB\...pathN\setup.exe on the server.

Installation Requirements for Linux

To install a DB2 product, the following operating system, hardware, and communications prerequisites must be met:

Package requirements

The following tables list the package requirements for SUSE Linux and Red Hat distributions for DB2 Viper partitioned servers.

• The pdksh Korn Shell package is required for all DB2 systems.
• A remote shell utility is required for partitioned database systems. DB2 supports the following remote shell utilities:
  • rsh
  • ssh

By default, DB2 uses rsh when executing commands on remote DB2 nodes, for example, when starting a remote DB2 database partition. To use the DB2 default, the rsh -server package must be installed (see table below). For a comparison between rsh and ssh , see the "Security issues when installing DB2" section of the Administration Guide: Implementation. If you choose to use the rsh remote shell utility, inetd (or xinetd ) must be installed and running as well. If you choose to use the ssh remote shell utility, you need to set the DB2RSHCMD registry variable immediately after the DB2 installation is complete. If this registry variable is not set, rsh is used. For more information on the DB2RSHCMD registry variable, see the Performance Guide book.

• The nfs-utils Network File System support package is required for partitioned database systems.

All required packages should be installed and configured before continuing with the DB2 setup. For general Linux information, see your Linux distribution documentation.

Software considerations

• A browser is also required to view online help.
• An X Window System software capable of rendering a graphical user interface is required if you want to use the DB2 Setup wizard to install DB2 or if you want to use any DB2 graphical tools.

Installation Requirements for HP-UX

DB2 Developer Workbench hardware, and communications prerequisites must be met:

Software considerations

• A browser is also required to view online help.

Appendix B. Uninstalling DB2 Viper Closed Beta

Uninstalling DB2 Viper Closed Beta on UNIX Systems

In this section, <DB2DIR> is used to denote the default installation directory, such as /opt/IBM/db2/V9.1 (UNIX) and /opt/ibm/db2/V9.1 (Linux).

1. Drop all DB2 instances and/or DAS that are associated with the installed DB2 Viper Closed Beta.

   You can find all DB2 Viper instances related to the <DB2DIR> by running the command <DB2DIR>/instance/db2ilist.

   You should delete all the databases before dropping your instances.

   For each instance on the list, you need to completely stop the DB2 instance including the database manager, DB2 application processes for the instance, and DB2 IPCs (you can run "<instance home>/ sqllib/bin/ipclean -a") as the instance user.

   Then you can run (with root authority) the following command to drop the related DB2 instances :

   <DB2DIR>/instance/db2idrop <Instance Name>

   You need to be very careful when dropping DAS. Since there can only be one DAS on the system, if you run the DB2 Viper Closed Beta dasdrop command, it will remove DAS even though it was created as a V8 DAS, which you may still wish to keep around.

   To check if DAS is associated with the DB2 Viper Closed Beta or previous versions of DB2, run the following command :

   <DB2DIR>/instance/ daslist

   This command will return the DAS user name.

   <DB2DIR>/bin/db2greg -dump | grep <DAS user name>

   This command will return information about DAS user.

   If you see /opt/IBM/db2/V9.1/das or equivalent as part of the returned information, it is a DB2 Viper Closed Beta DAS. You should remove this as part of the clean up process for DB2 Viper Closed Beta.

   If you see /opt/IBM/db2/V8.1/das or equivalent, then this is a Version 8 DAS. Do not run dasdrop unless you really wish to remove this from the system. If you had created a DAS from the DB2 Viper Closed Beta, then you can drop the DAS with the following command (with root authority):

   <DB2DIR>/instance/ dasdrop <DAS Name>

2. Uninstall DB2 from <DB2DIR>

   You can run the following the command with root access to completely uninstall the DB2 Viper Closed Beta installed at <DB2DIR>:

   <DB2DIR>/install/db2_deinstall -a

   You may ignore minor errors reported by db2_deinstall script and manually clean up any left-over files under <DB2DIR>.

Uninstalling DB2 Viper Closed Beta on Windows 32-bit Systems

You must stop all running DB2 services prior to uninstalling DB2. To uninstall DB2, from Add/remove programs choose and click on Remove.
After removing DB2 by using "Add/Remove Programs", do the following steps for the DB2 copy that is being uninstalled.

1. Remove all files left in the install path (the sqllib directory) from your machine.
2. Remove DB2 entries left in the start menu.
3. Remove registry entries under the "HKEY_LOCAL_MACHINE\Software\IBM\DB2" key.
4. Remove DB2 registry entries under "HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\" and having the form DB2*, where * is any string of characters. Please review each key you delete to make sure they are DB2 services. Removing keys that are not related to DB2 may cause problems with the computers
5. Remove all DB2 entries from your environment variables, either by deleting the variable, or by editing it to remove the entries corresponding to DB2. For example, the PATH variable should no longer have the DB2 install path mentioned anywhere, nor should CLASSPATH have any install paths or paths to db2 files left in it (do this only if the DB2 copy that is being uninstalled is the last copy on the system).
6. Reboot your machine.

Appendix C. Uninstalling DB2 Native XML Alpha

Uninstalling DB2 Native XML Alpha on AIX 64-bit Systems

To get a list of existing DB2 instances:

login as root

/opt/IBM/db2/V9.1/instance/db2ilist

To cleanup and stop each DB2 instance on the system:

1. Login as the instance user
2. Stop all DB2 instance processes
   Run the following command:
   db2 terminate
3. Drop all DB2 databases
   To get a list of the existing databases:
   db2 list db directory

   To drop each of the listed databases:
   db2 drop db <dbname>
   

4. To stop the DB2 instance:
   db2stop force
5. To remove IPC resources for each DB2 instance:
   ipclean -a

To kill any lingering DB2 processes:

1. login as root
2. ps -ef | grep db2
3. kill -9 <processID>

   If a process keeps re-spawning, stop it by:

   /opt/IBM/db2/V9.1/instance/bin/db2fmcu -d

   kill it

To drop each DB2 instance on the system:

1. login as root
2. /opt/IBM/db2/V9.1/instance/db2idrop <instUserID>

   where <instUserID> is the instance user ID.

   If any error occurs, you need to remove the corresponding sqllib directory manually.

If you have created a DB2 Administration Server (DAS) using DB2 Native XML Alpha, you may need to stop the DAS:

1. login as the DAS user
2. db2admin stop
3. login as root
4. /opt/IBM/db2/V9.1/instance/dasdrop <dasUserID>

   where <dasUserID> is the DAS user ID.

To remove any remaining sqllib directories:

1. login as the instance user
2. rm -rf /home/<instUserID>/sqllib

   where <instUserID> is the instance user ID.

To remove any unused modules in memory:

1. Login as root.
2. /usr/sbin/slibclean

To remove DB2 Native XML Alpha:

1. rm -rf /usr/opt/db2_08_01
2. rm /opt/IBM/db2/V9.1 (this should be just a soft link)

Uninstalling DB2 Native XML Alpha on Windows Systems

You can not uninstall DB2 Native XML Alpha using Windows "Add/Remove" programs option due to changes in DB2 files and directories. We recommend that you use the following instructions to uninstall DB2 Native XML Alpha from your system.

1. Drop DB2 Administrative Server (DAS).

   Use "db2admin" utility to stop and drop DAS for your installation of DB2.

   Start DB2 CLP window, from Start/ALL Programs/IBM DB2/Command Line Tools/ Command Line Window.
   In the DB2 CLP window, issue the following commands to stop and drop DAS:
   db2admin STOP
   db2admin DROP

2. Drop all DB2 Instances.

   Using "db2idrop" utility drop all instances defined for your installation of DB2.

   db2idrop <InstanceName>
   e.g. db2idrop DB2

3. Stop all running DB2 processes.
   Issue the following command:
   killdb2 or killdbm
4. Uninstall the DB2 product.
   1. Close all programs
   2. From a command prompt, go to the windows Installer directory:
      c:\Windows\Installer or c:\WinNT\Installer
   3. Run following command to uninstall the DB2 product

   msiexec /x {D8F53726-C7AD-11D4-9155-00203586D551} FORCE_UNINSTALL=Y

   This command will ask you "Are you sure you want to uninstall this product ?" Select "Yes". This will begin force uninstall of above package. This will take several minutes to complete.

5. Environment Variable Cleanup.

   Go to the Control Panel, click System, click the Advanced tab and click Environment Variables.
   Remove following DB2 environment variables:
   DB2INSTANCE
   DB2TEMPDIR

   Remove references to SQLLIB directory from following environment variables:
   CLASSPATH
   INCLUDE
   LIB
   PATH

6. Clean up registry.

   Use "regedt32" program to delete following registry entries:

   1. Delete DB2 registry key from HKEY_LOCAL_MACHINE/SOFTWARE/IBM
   2. Delete DB2 registry key from HKEY_CURRENT_USER/SOFTWARE/IBM
   3. Remove entry "db2systray.exe DB2 " from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
7. Remove DB2 services.

   On Windows XP, you can run following command to remove DB2 services if any:
   sc delete "DB2-0"
   sc delete "DB2DAS00"

   On Windows 2000, you can remove service entries using "regedt32".
   Start "regedt32", navigate to following registry entry:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
   Delete keys, "DB2-0" and "DB2DAS00"

8. Clean up services file.
   1. Use " notepad" to open "services" file from [Windows]\system32\drivers\etc directory
   2. Remove any entries related to DB2.
9. Remove SQLLIB.

   Delete the entire SQLLIB directory, e.g.
   C:\Program Files\IBM\SQLLIB

Appendix D. Notices

YOU UNDERSTAND THAT THE PRODUCT AND ANY LIMITED TECHNICAL SUPPORT ARE BEING PROVIDED TO YOU "AS IS" WITHOUT ANY WARRANTIES (EXPRESS OR IMPLIED) WHATSOEVER, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY, QUALITY, PERFORMANCE OR FITNESS FOR ANY PARTICULAR PURPOSE. Furthermore, IBM, its supplier, agents and employees accept no liability for damages you may suffer as a result of the technical support provided or not provided, or your use of the Product, including, but not limited to, any damages claimed by you, based on any third party claims. In no event will IBM, its suppliers, agents and employees be liable for any indirect, special, punitive, exemplary or consequential damages, even if IBM has been advised of the possibility of their occurrence.

Although IBM will try to answer technical support questions you may have regarding your use of the Product, this assistance does not obligate IBM to provide support or maintenance services for the Product at this time.

IBM does not warrant or guarantee that the operability of any of your applications running with the Product will be maintained with any generally available versions of the Product or that any version of the Product will ever be made generally available or marketed.

Use of the materials is subject to the IBM agreement for DB2 Viper Release Candidate 1 program.

Trademarks

Company, product, or service names identified in the documents of the DB2 Viper Release Candidate 1 documentation library may be trademarks or service marks of International Business Machines Corporation or other companies. Information on the trademarks of IBM Corporation in the United States, other countries, or both is located at http://www.ibm.com/legal/copytrade.shtml.

The following terms are trademarks or registered trademarks of other companies and have been used in at least one of the documents in the DB2 Viper Release Candidate 1 documentation library:

Intel, Intel Xeon, and Pentium^(R) are trademarks of Intel Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft^(R), Windows, Windows NT^(R), and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.