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).

Tips on the ITM Agent for Maximo (product code MI )

I recently found the Tivoli Monitoring Agent for Maximo 7.1.1 Feature Pack and wanted to share some tips on using it. You can find the Feature Pack (with downloads) here:

https://www-304.ibm.com/support/docview.wss?q1=itm&rs=3214&uid=swg24025477&context=SSLKT6&cs=utf-8&lang=en&loc=en_US

The instructions for installing the agent assume that you have Maximo, your ITM TEMS and ITM TEPS all on the same Windows machine, which I imagine would not be the case for most customers. You *can* install the TEMS and TEPS support on a non-windows machine using the following commands:

installIraAgentTEMS.sh /opt/IBM/ITM


installIraAgentTEPS.sh /opt/IBM/ITM

Where the first parameter is your ITM install directory. You can then install just the agent on a Windows machine with:

installIraAgent.bat C:\IBM\ITM

The agent itself is ONLY installable on Windows. However, this can be ANY Windows machine you want - it only needs to be able to access your Maximo server via URL. NOTE: The agent does get some information from the Log file dir that you specify; if you install the agent on a machine that is not your Maximo server, this data will not be available. (I'm not certain exactly what information it gets from the logs.)

A BIG caveat of the agent is that you CAN NOT use it if you have configured Application Server Security for authentication and authorization with Maximo. (I didn't test out the scenario of configuring Application Server Security only for authentication due to time constraints). So you can only use the agent to monitor a Maximo installation that is configured to use Maximo security.

The next tip has to do with configuration. When you configure the agent, you're required to provide a few pieces of information:

Instance Name: Do NOT use "maximo" as the value! I found this out the hard way - it simply doesn't work if you do this. I used "MXServer", but it looks like you can use anything OTHER than "maximo".

Log file dir: This is the location of your application server log files. For example:

/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/MXServer

Port: This is the port you use to access Maximo. The default is 7001, which is the default http port for WebLogic. If you're using WebSphere, you should change this to 9080 for http access (or 9443 for https).

Java Home Directory: This can be set to any Java 1.5 (or above) install location on the system. I set mine to:

E:\IBM\SMP\sdk

Another tip is that you do NOT need to configure Maximo Performance Monitor for the agent to work.

The last tip is on usage, once you get the agent up and running. Let it run for a several minutes before assuming it's not working correctly. It just takes a few minutes to capture some of its data. Once it up and running correctly, the table in the Performance Object Status workspace should look similar to this:



SysInfo SysInfo ACTIVE NO ERROR
DataBaseInfo DataBaseInfo ACTIVE NO ERROR
InstalledApps InstalledApps ACTIVE NO ERROR
License License ACTIVE NO ERROR
InstalledProducts InstalledProducts ACTIVE NO ERROR
DBConnections DBConnections ACTIVE NO ERROR
MemGaugeForAllSrvrs MemGaugeForAllSrvrs ACTIVE NO ERROR
RuntimeMXBean RuntimeMXBean ACTIVE NO ERROR
Memory Memory ACTIVE NO ERROR
MemoryGauge MemoryGauge ACTIVE NO ERROR
MBOCountGauge MBOCountGauge ACTIVE NO ERROR
UPSGauge UPSGauge ACTIVE NO ERROR
CronTasks CronTasks ACTIVE NO ERROR
EscalationErrorLog EscalationErrorLog ACTIVE NO INSTANCES RETURNED

PLAYterm: a New Way To Improve Command Line Skills

PLAYterm: a New Way To Improve Command Line Skills: chrb writes "Linux Journal points out PLAYterm, an interesting project that offers up recordings of Linux command line sessions, with the aim of helping viewers to improve their skills by watching gurus at work." And there's no bad excuse to link to Neal Stephenson's excellent (and free-to-download in delicious zipped-text form) In the Beginning was the Command Line.

Read more of this story at Slashdot.

I think this is a great resource for Windows people learning UNIX/Linux, and also for Linux people who just want to learn about some new commands.

How to create a lock on a DB2 table

I spent a while figuring this out (to set up a problem/resolution scenario for ITCAM) and figured I would share.

By default, DB2 has auto-commit turned ON. So any time you run a SQL statement, it's automatically followed by a COMMIT. To change this, the easy way is:

db2 +c "delete from your_table_name where your_where_clause"

Then any other application or process trying to read or write this table will have to wait until the lock is cleared before returning. So if you open another window and run 'db2 select * from your_table_name', it will just sit there.

To clear the lock, run:

db2 commit

More info is here:

https://www-304.ibm.com/support/docview.wss?uid=swg21297813