How to update DB2 after changing your Windows hostname

Working with a bunch of VMs, I often have to change names, IP addresses, etc. Today I finally got tired of having an extra (non-functioning) entry in my DB2 control center because I changed the hostname of one of my DB2 servers. Happily, I found this great entry on how to do it:

http://www.dbforums.com/db2/1080165-changing-host-name.html#post4010147

However, after going through the steps, you need to restart your database administration server service, named DB2DAS - DB2DAS00. Once you do that, your new hostname appears, and the default instance (named DB2) is also there. Any non-default instances can just be manually added.

GBS YouTube Channel

Gulf Breeze Software has just created a YouTube channel.   Four videos have already been posted and with plans on posting more videos in the future.  If you have any recommendations/requests please post them in the comments.

YouTube Channel
http://www.youtube.com/user/gulfsoft

ITM Private Situations and Private History
http://www.youtube.com/watch?v=QF1LVnCDuQY

ITM Agent Builder HTTP Provider
http://www.youtube.com/watch?v=j6LJr8zg4Uk

ITM Disk Situation Override
http://www.youtube.com/watch?v=mGNPgev4v18

ITM Dynamic Logical Views
http://www.youtube.com/watch?v=4f6BsRaNjKQ

Using Non-ITM data in TEPS - Updated

A while back, we posted a blog article on how to add custom datasources to TEPS.  The problem with that is the database credentials are stored in plain text format and TEPS now expects the credentials to be encrypted.  Here is an updated and Tivoli supported way to use Non-ITM data in TEPS using ODBC.  

Prerequisites

You should have  aworking ODBC connection to the datasource.  Must be cataloged as a system datasource in Windows. 

Steps to add custom datasource

1. Open Command prompt and run "tacmd login" to logon to TEMS.
2. Run the following command to add custom datasource with password. The command will encrypt the password and store it in kfwcma.ini under CNPS directory. 
   "tacmd configureportalserver -d <CANDLEHOME> -s DSUSER1 -p DSN=<ODBC-DSN> UID=<user> PWD=<password>".
3. Verify the datasource entry by running the following command.
   "tacmd configureportalserver -s DSUSER1 -v"
4. Recycle the portal server.

An Example

In this case, I created a custom data source to point to Omnibus REPORTER database and created a custom query to pull all the REPORTER_STATUS table entries.  After creating necessary views to use the Custom Query, the data can be seen in TEPS.  Please see the attached screenshot.

Manually Setting the MOD Level for the ITCAMfAD DataCollector

Normally, you would change the MOD (Monitoring On Demand) level for the ITCAMfAD DC (also used as the DC for older versions of ITCAMfTrans) using the Managing Server. In some cases, however, you may not have a Managing Server, or you may not have access to it. In such cases, you can manually set the MOD level by editing the file:

WASDC_install_dir/runtime/server_name/am.mod

On my machine, the full path is:

/opt/IBM/ITM/lx8266/yn/wasdc/7.1.0.2/runtime/was70.aimssrv1.gulfsoft.comNode01.server1/am.mod

The default value of this file is a single line with the value 1, corresponding to MOD Level 1. To change this, open the file in a text editor and change the value to 2 or 3 (MOD Level 2 and 3, respectively).

One particular case where this is useful is if you don't have an ITCAMfAD MS and you want to capture JDBC calls for topology mapping in ITCAM for Transactions with TTAPI. The data collector will only collect this data in MOD levels 2 and 3, and the only way to set this without a Managing Server is by editing this file.

A Taxonomy of Visualization Techniques

Not necessarily related to Tivoli, but this is a very thorough article on visualization techniques:

http://queue.acm.org/detail.cfm?id=2146416

GBSCMD Performance Improvement Tip

GBSCMD is a Gulf Breeze developed utility for performing ITM operations from command line using SOAP.  If you are running GBSCMD, you will probably notice performance degrade when the amount of SOAP response is huge.   For example, if you are fetching list of all managed systems or all situations in an environment with thousands of systems/situations, gbscmd might take quite sometime to get this information.  

 

This performance degrade is due to the built-in XML parser used by XML::Simple module. To overcome this issue, you can simply set an environment variable to use a different/more-efficient parser and that will do the trick.

 

For example, run  "export XML_SIMPLE_PREFERRED_PARSER=XML::Parser" in your environment before running gbscmd and you will notice much better response times even for large datasets. 

 

Hope this helps.

Working with the Deployment Engine

So the IBM Deployment Engine (aka ACSI, or Autonomic Computing Solution Installer is what I believe the acronym stands for) is a really nice product and works very well if you read the documentation and warnings. As luck would have it, I forgot to read some of the documentation and warnings, so I was able to learn some things.

The OMNIbus documentation states that if you use the DE as a regular user, then as root, that all installs from that point forward will only use the DE instance that was installed by root (the global instance). It also states that if you uninstall the global/common instance, then the DE is uninstalled everywhere.

The situation that brought me to this point is that I installed TBSM 6.1 on Linux as the user 'netcool' (so it uses a user-specific DE). I then tried to install CCMDB 7.2.1 on the same machine as the user 'root'. This failed early in the process, but not before a new global/common DE was installed. I gave up my CCMDB install dreams and proceeded to install an OMNIbus probe as the user 'netcool'. This gave me an error that I was currently using the global DE on an installation that had been performed using my user-specific DE and I should abort the installation. After reading the above OMNIbus documentation, I didn't want to uninstall the global DE (for fear that it would wipe out everything and I wouldn't be able to upgrade any products). However, since I had a copy of my VM, I gave it a shot. What I did was:

as root:

cd /usr/ibm/common/acsi/bin
export SI_JAVA_HOME=/usr/ibm/common/acsi/jre
./si_inst -r -f

This scared me a bit because it did COMPLETELY remove the /usr/ibm/common/acsi directory and killed all of the acsi processes ('ps -ef | grep acsi' showed nothing at this point). But my ~netcool/.acsi_* directories were still there (I don't know why, but I have two of these directories - ~/.acsi_netcool and ~/.acsi_myserverhostname). At this point, I re-ran the probe installation as user netcool (nco_install_integration), and I got no error messages, and the install information was added correctly to my local DE instance.

And the lesson I learned is that once you install any DE-based product on a machine as a non-root user, all of your subsequent DE-based installs need to be done as non-root users (it doesn't need to be the same user for different products, but you don't want to install anything DE-based as root).