How to uninstall IBM DB2 Content Manager Version 8.3 products if fix packs are also installed

Question

When you run the product uninstall program, you see the following error:

"You must uninstall the most recently installed fix pack before running this uninstall."

Cause

Fix packs must be uninstalled from the system in reverse order before you can uninstall the product.

Answer

To uninstall the latest fix pack, run the command:

IBMCMROOT/fixpack/cm/VERSION/_uninstall/uninstallUpdate 

where VERSION is the version number of the fix pack.

Tip: To determine the current version installed for each IBM® DB2® Content Manager product, run the command IBMCMROOT/bin/cmlevel.

If multiple fix packs have already been applied, run the uninstallUpdate command for each fix pack starting with the latest fix pack and then continuing in reverse order. For example, if you have DB2 Content Manager fix pack 1, fix pack 3, and fix pack 6 installed, you should first uninstall fix pack 6, then fix pack 3, and then fix pack 1.

Once all fix packs have been uninstalled, run the uninstall program for the product you want to remove.
For DB2 Content Manager:
Run IBMCMROOT/_uninstCM/uninstall-cm.exe
For DB2 Information Integrator for Content:
Run IBMCMROOT/_uninstII4C/uninstall-ii4c.exe
For eClient:
Run IBMCMROOT/_uninstEC/uninstall-ec.exe

Caching Issue in WebSphere Portal version 6.1, 7.0 and 8.0

Currently Committed database setting - Applies to DB2 v9.7 or higher and WebSphere Portal version 6.1 and 7.0

 

DB2 V9.7 introduced a new default behaviour for isolation level cursor stability (CS) (see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0053556.html).
In WebSphere Portal this has implications for the cache invalidation strategy related to transactions. The new DB2 default behaviour for isolation level cursor stability (CS) is to NOT block code that wants to read data which is still being worked on in an uncommitted transaction in another thread (DB2 returns the result, as if the other transaction would not exist). But WebSphere Portal version 6.1 and 7.0 cache invalidation and refill strategies rely on the blocking at database level. With the new 'currently committed' default setting, stale data in Portal caches can occur.

Starting with Portal version 8.0 the setting of CUR_COMMIT to ENABLED is supported.

Besides the fact that CUR_COMMIT must be set to DISABLED for WebSphere Portal version 6.1 and 7.0, WebSphere Portal development does not expect a performance degradation when changing the value of CUR_COMMIT from ENABLED to DISABLED. For some scenarios with long database transactions, it could be that response times increase due to additional waits for updated data.

The setting of CUR_COMMIT is applied at database level. Therefore it is required to set CUR_COMMIT to DISABLED for the Portal database(s), containing the Portal database domains release, community, customization, jcr, feedback, and likeminds.

Disabling CUR_COMMIT in DB2 Version 9.7:

Ask your DB2 administrator to ensure that CUR_COMMIT is disabled by carrying out the following steps (for each of the Portal databases):

1. Connect to the runtime database:
   $ db2 connect to
   where represents the name of the database.
   
2. List the CUR_COMMIT parameter:
   $ db2 get db cfg show detail | grep CUR_COMMIT
   The output should look like this:
   Currently Committed (CUR_COMMIT) = DISABLED DISABLED
   
3. If the values are anything other than two times DISABLED (one for the current setting used, the other for the delayed setting specified in the configuration), change the value to DISABLED:
   $ db2 update db cfg using CUR_COMMIT DISABLED
   
4. Close the database connection:
   $ db2 connect reset
   
5. Check that no other application is connected to the database,to make the change effective (This e.g. requires to stop the Websphere Portal Server that uses the database). List the connected applications like this:
   $ db2 list applications for db
   where represents the name of the database.
   The output should look like this:
   SQL1611W No data was returned by Database System Monitor.
   
6. Ensure that the settings are correct by repeating the steps 1. and 2.

Full technote and source : http://www-01.ibm.com/support/docview.wss?uid=swg27037929&myns=swgws&mynp=OCSSHRKX&mync=E#!