TPM 5.1.1 Documentation

Posted by: martinc on Dec 21, 2007 - 04:55 PM

IBM has provided a document on the components to download for install and updated the Info-Center
Download information http://www-1.ibm.com/support/docview.wss?rs=1015&uid=swg24017302

There is information for all the OS platforms, you just have to scroll down. For some reason it is not quite set up like previous pages. Oh well.

Info Center: http://publib.boulder.ibm.com/infocenter/tivihelp/v20r1/index.jsp

TPM 5.1.1 is now available

Posted by: martinc on Dec 21, 2007 - 02:46 PM

The Christmas present everyone was waiting for :)
So what is new and improved?

The biggest focus on the new version was the installer. Anyone who has tried to install TPM 5.1 knows that it just did not work. I know that installs for me were < 50% successful on the first try. Even with the exact same VM images from attempt to attempt. In the new version, I did not have a failure on the 4 times that I installed. Sweet!

There is also more support for different topologies. In the previous version, getting TPM to use a remote database was a post install step. Now it is part of the installer.

Some of the new features are:
Agent less inventory scanning - there is no longer a requirement to have the agent installed on a system to perform an inventory scan. The scan will copy the required files to the target, initiate the scan and return the results to the DCM

Web Replay - This was available in a "beta" in 5.1 but is now part of the install. Web replay allows for some automation of tasks. Some tasks within TPM take many steps to complete and for the most part do not require any input. A recording of the steps can be done to "automate" some steps and stop at prompts for others.

Unknown device management - When discovering devices and an error is encountered, the device is dropped and not recorded in the DCM. Now the device will be recorded but will require some manual steps to complete the discovery. This is useful when a device is discovered but the user name and password are not correct. A new discovery can be done with the correct information on the unknown device.

Enhanced Discovery - When discovering SMB or SSH devices, the discovery can be done in one discovery configuration rather than two separate discovery configurations. This is mainly a time saver so that the same subnet does not need to be scanned twice.

There have also been many changes in the user interface to improve performance and readability.

My Comments
So far I have been pretty impressed by the installer and some of the changes made to the interface. I know that the agent less inventory scanning has been something that people were asking for and it does work! As I said before, the installer did work very nice. One of the big changes in the install is that by default it only uses local OS authentication (much like the fast start install). There is documentation and scripts to allow for easy configuration of TDS or MSAD (read only).

I will get some screen shots and other comments in the new year.

So Merry Christmas and Happy New Year!

Martin

Tivoli Common Reporting (TCR) uses the ZeroG InstallAnywhere installer

While many Tivoli products use the InstallShield Multi-Platform (ISMP) installer, TCR uses Zero G installer.

This little difference is important if you want to reinstall the product. Specifically, ISMP uses the vpd.properties file as its installation registry. Zero G, on the other hand, uses a file named .com.zerog.registry.xml (notice that it begins with a dot, so it's a hidden file). So if you need to delete the product and start over, you need to edit or delete this file, also. If you only remove the install directory, when you run the installer, it will just tell you that Tivoli Common Reporting is already installed, and won't reinstall it.

Using BIRT for TDW Reporting

There has been alot of interest in BIRT lately with the release of Tivoli Common Reporting 1.1.1 to GA, so I'm posting a link to part of my TUG presentation on using BIRT..

TUG BIRT Presentation

Actually searching all files when searching for text

For quite a while I have always been annoyed by the search in Windows. I thought it was great that you could use the search to look for text inside a file, just like grep. Of course in usual Microsoft fashion, search all files does not mean to actually search all files.

So finally I became so annoyed with this, I went to see if there was a solution.

I did find the solution and I thought I would share the link
Using the "A word or phrase in the file" search criterion may not work

Hope this helps someone.

Where Wizards Fear To T"h"read

Since PERL is a tool of choice for many of us Tivolians when it comes to automations and integrating systems with Tivoli products, I thought it could be of help to others to throw out a few gotchas I've encountered programming Perl threads. Please note that I'm not referring to "forking".

Though Perl threads can help speed up things in a Tivoli automation or integration script, they can also add headaches and frustration to ones life. The following three pointers should help reduce some of the strive...

1. Using nested data structures with PERL THREADS.

When using threads it is usual to share data. Sharing complex data structures works very well for a single threaded (single process) PERL script. But once the main process starts producing child threads, then hell breaks loose with the complex data structure as PERL can as of the writing of this document, deal with ONLY one level deep references to a SHARED data structure like an array or hash.
If you encounter and error like:

Invalid value for shared scalar at ...

then you've nested too much. Keep your reference to shared arrays and hashes to one-level down and you'll be ok.


2. Creating an ALARM signal handler within a child thread.
Often in Tivoli a person will call "w" command/s within a PERL program to perform some operation on a Tivoli resource. But it often happens that a "w" command hangs or takes too long to complete. What many often do is create an ALARM to timeout the command so the process continues execution when some specified time has elapsed. This usually works OK in a single thread program, but things start going out of hand when there's more than one thread executing in a PERL program. What happens with threads is that instead of timing-out the particular intended call within a CHILD thread, the whole PERL program quits executing! That is the main thread and its children threads die!!! The one work-around I've always found effective is to include code that looks as follows in the MAIN program flow. Make sure this code appears in the main thread and NOT in a child-thread.


$SIG{ALRM} = sub {}; #Just here to workaround the threads "Alarm clock" bug


That amazingly does the trick!


3. Handling the CTRL C interrupt within a threaded Perl program.
To avoid resource contention, often a person would prevent more than one instance of a PERL program from running by creating a lock-file at the begin of the program and then removing the file just before end of the program. But a problem comes when for some known or unknown reason, the PERL program receives an INT signal and terminates after creating the lock-file, but before executing to a point where the lock-file gets removed. Thus preventing any subsequent run of the program. It's easy to circumvent this situation and handle the signal in a single thread PERL program, but it can be a pain doing like-wise in a multi-threaded PERL program where a simple $SIG{INT} may do anything but catch the interrupt. For instance the norm would be to do something like:

$SIG{INT} = sub { "code that removes the lock-file"; die};

Trying to handle the interrupt this way in a multi-threaded PERL program may actually result with the program dumping core. Including the following chunk of code/subroutine most often does magic and beautifully handles the interrupt signal without fail:



use sigtrap qw[handler sig_handler INT TERM QUIT PIPE];
use Swith;

sub sig_handler {
my($sig) = shift;
print "Caught signal $sig";

switch($sig) {
case ["INT","TERM","QUIT"] {
unlink "/tmp/dashlock";
print "Exiting";
exit(0);
}
case "PIPE" {
print "Continuing";
}
}
}



I'm sure the above is not all there is on PERL threading gotchas, I however hope the pointers save you time and heart-ache should you have to deal with Perl threading in the near future and encounter similar issues.

That's all folks!

Adios,
J. Napo Mokoetle
"Even the wisest man is yet to learn something."

Eclipse plugin to access the TADDM API

I realize that this won't be interesting to many people, but I wrote an Eclipse plugin to access the TADDM API.

You can download the plugin from http://www.gulfsoft.com/downloads/TADDM_API_plugin.zip . The plugin requires Eclipse 3.3 and the Web Tools Platform.

To install the plugin:

1. Close Eclipse if it is running
2. Extract the TADDM_API_plugin.zip file into your eclipse directory. It will place the file com.gulfsoft.wst.xml.ui_1.0.0.200711131411.jar in your plugins directory.
3. All of the other help for the plugin is available from>Help->Help Contents in Eclipse. The help is found under the topic TADDM API Plugin.