As a Tivoli consultant, I’ve had to tweak, torque and tune ITM v6 to fulfill requirements not met out of the box. Several of my clients have felt ripped off by IBM for having paid for a product billed as covering best practices out of the box, only to discover, there is significant development costs involved.

I’m going to itemize and update the shortcomings as I think or run across them, and in all fairness, update if ITM fills the void.

Situations

1. Attributes, values and situation specific data is not passed to the ‘Take Action” command
   • Typically this is passed in the shell’s environment
   • However, these important pieces of info ARE passed to the EIF
2. Inability to determine what situations are running on which systems, or reversed, inability to derive which situations are running on any particular system

Windows Agent

1. No regular expressions for directory/file matching

Unix Agent

1. No regular expressions for directory/file matching (Unix and Linux)

Oracle Agent (ITMfDatabases)

1. (<= v6.2.0) Does not detect listeners if dynamically configured

Not that there is a lot to the TDW layout, but knowing the schema assists in the documentation process and developing queries and procedures of the TDW (Tivoli Data Warehouse).

Make short work of this by using the opensource tools of SchemaSpy and Graphviz

SchemaSpy is a jar file that supports over 21 DBs, including the 3 supported by ITM TDW (Oracle, Sybase, MSSQL) and is run from the command line to generate a html directory of content about the interrogated schema.

ITM 6.2 FP1 contains several new and changed T/EC class changes, ranging from new classes, new slots, and only ONE new slot (omnux_value replacing kux_value).

**I have not seen an ITM event containing kux_value nor omnux_value, but to be safe, I added the old ‘kux_value’ slot to the kux.baroc file.

TOTAL: 22 baroc files

Reference: http://help.mosso.com/article.php?id=180

Your script is calling for the “REMOTE_ADDR” and receives the IP of a server in front of one of our back-end servers. The web facing server is then passing the scripts output without giving the expected REMOTE_ADDR of the visitor. In order for your scripts to recognize that they are on a cluster and log the correct IP of your visitors, you will need to replace and add the code below.

For PHP:
Locate any lines of code that are similar to this snippet of code,
$_SERVER['REMOTE_ADDR'];
And replace it with this snippet of code,
$_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

For ASP:
Locate any lines of code that are similar to this snipper of code,
Request.ServerVariables(“REMOTE_ADDR”)
And replace it with this snipper of code,
Request.ServerVariables(“HTTP_X_CLUSTER_CLIENT_IP”)

My fix for this required a unix shell (if you’re on a Windows look at installing cygwin on your system.

# Ftp your web content down to your local system

$ for file in `find <path_to_files> -exec grep -l REMOTE_ADDR {} \;`; do base=`basename $file`; sed ’s/REMOTE_ADDR/HTTP_X_CLUSTER_CLIENT_IP/g’ $file > /tmp/$base; grep HTTP_X_CLUSTER_CLIENT_IP /tmp/$base >/dev/null 2>&1 && grep REMOTE_ADDR $file && echo “Updated $base” && mv
/tmp/$base $file; done

# Then simply upload the changed files to your system.

Instead of copying a large tar file over ssh then extracting, take care of the whole process with one command:

PUSH METHOD:

cat  tarfile | ssh –C user@remotehost “(cd targetdirectory && tar –xf -)”

This will stream the tarfile over a compressed ssl tunnel and the other side will only extract if the target directory exists. The “cd targetdirectory” piece I used as a good prevention to blowing files all over an undesired/unexpected location.

PULL METHOD:

ssh -C user@remotehost”cd sourcedirectory; tar -cvf – dir_or_file” > outputfile

This is the opposite method, obviously.  Please note, the output of the SSH needs to be redirected to an output file.