John Alvord, IBM Corporation
Draft #7 – 26 October 2015 – Level 0.58000
In some installations, the ITM agents are virtually never updated. New systems get new agent levels and old ones are not touched. This increases the cost of ownership since avoidable defects are experienced. This project reports on Tivoli Enterprise Maintenance Agent [TEMA] maintenance levels. TEMA is a part of the the agent side logic that connects with the TEMS, runs situations, collects real time data request and many other tasks. This shared library is usually bundled with the OS Agent. It has its own collection of APAR fixes. I counted 120 APARs from the first ITM level to the upcoming ITM 630 FP4 level.
The report counts how many problems could be avoided using three upgrade OS Agent scenarios:
1) Upgrade to current highest fixpack level installed,
2) Upgrade to the maximum fixpack level in current release – requires TEMS upgrade also
3) Upgrade to highest fixpack in latest release – requires TEMS upgrade also
Following is a report section that names the APARs fixed at each level.
Following are more report sections going to increasingly detailed levels so you can focus on specific cases easily.
Note: The report assumes the availability of ITM 630 FP4 which is expected to be published in several weeks.
The data is gathered using SQL dumps using the KfwSQLClient program which is part of TEMS. This is rapid and simple to use – since it uses a preexisting connection.
The following assumes the default install directory. The work is done on the system which runs the TEPS. You can certainly do this other ways. For example you could capture the data at the TEPS and then copy the files somewhere else to process. If you are using a non-default install directory then the shell files will need to be modified. The choice of where to store the program objects is arbitrary.
The package is census.0.58000. It contains
1) Perl program agentcensus.pl – standing for Agent Census Scorecard.
2) A agentcensus.cmd [Windows] shell command to run the SQL statements.
3) A agentcensus.tar file which contains a agentcensus.sh file. This avoids problems with the line endings. To use untar into the installation directory.
4) If the install directory is not the default an environment variable must be set
I suggest these all be placed in a single directory. For Windows you need to create the tmp directory and the sql subdirectory. For Linux/Unix create the sql directory. For Linux/Unix you will need to make the agentcensus,sh executable “chmod 777 agentcensus.sh”
No CPAN modules are needed for this package.
Running the Program
a) cd /opt/IBM/IBM/tmp/sql
b) If not using default install directory run specify like this: export CANDLEHOME=/opt/IBM/ITM
c) sh agentcensus.sh
d) perl agentcensus.pl -lst
b) If not using default install directory run specify like this: SET CANDLE_HOME=c:\IBM\ITM
d) perl agentcensus.pl -lst
One file is created: agentcensus.csv which is the report.
First is a view of the beginning of the report
The TEMA section is the meat of the report. Note that there are 6861 managed systems [line 3] and 5589 total TEMAs identified. Subnode agents do not have TEMAs which explains the difference.
Here is the most important section
|Known Defects fixed||Update Option|
|7.48||Maximum TEMA level currently present|
|14.55||Highest TEMA Level of installed release|
|39.33||Highest available release|
For example, if the maximum level currently installed in ITM 623 FP3, that is a TEMA level of 06.23.03. The highest level of ITM 623 available is FP5 or 06.23.05. The highest available release [in December 2014] is expected to be ITM 630 FP4 or 06.30.04.
The table means that if you upgraded all OS agents to the 06.23.03 level, you would avoid an average of 7.48 defects per agent.
If you upgraded the TEMS and all the agents to 06.23.05 level, you would avoid an average of 14.55 defects per agent.
If you upgraded the TEMS and all the agents to 06.30.04 level, you would avoid an average of 39.33 defects per agent.
Of course if an agent is already at the higher level, it will not experience the problems.
Not all APARs apply to all agents. For example some will apply to new features – like autonomous mode – that are not being used. Some might apply to specific platforms, like Solaris Unix OS Agent, and you might not have any Solaris systems. To be more precise you would need a lot of research. However at a high level these numbers represent very well how many TEMA issues your ITM environment is subject to solely because of what maintenance levels are installed. Reducing the number of such avoidable issues will reduce the number of problems experienced and lead to a smoother experience.
Following that section is a report on exactly what APARs are fixed at which levels. It shows the level, the publish date and the list of TEMA APARs. It is largely complete although I am still researching ITM 6.1 FP6. In many ways that doesn’t matter so much because ITM 6.1 has gone out of service except for special support contracts.
If you use IBM Support you can view the APAR details by browsing to URL
Next is a view that shows you details about the missing TEMA APARs
This shows the APAR, the ITM version that delivered the APAR [with the OS Agent], the count of agents potentially affected and the APAR abstract text.
You should use this as a guide to determine if the APAR is of interest in your environment. For example if it relates to Private Situations, you can ignore that if only Enterprise situations are in use. As before you can get some more details by referencing the APAR URL
Next is a high level view starting with the TEMSes and then each agent type independent of what TEMS it reports to,
For most agents you will see a version like this 06.21.00:02.20.00.05. The first part 06.21.05 is the TEMA level and the second part 02.20.00.05 is the Agent level including the intermediate fixpack if available.
Finally comes an even more detailed section, where each TEMS is shown, the agents reporting and also the managing agents and subnode agents.
The idea is to provide enough information in the report so you can drill down what ever level you need to understand the condition.
At the very end is a random collection of advisory messages from some “should never occur” conditions. Mostly these are missing references which have little or no practical impacts. Contact IBM Support in case you want to work on those issue.
This report shows the impact of back level TEMA support.
History and Earlier versions
If the current version of the Agent Census Scorecard tool does not work, you can try previous published binary object zip files. At the same time please contact me to resolve the issues. If you discover an issue try intermediate levels to isolate where the problem was introduced.
parse_lst handle null chunks correctly
Photo Note: “Sorry About the Mouse” – credit IBMer Joachim Schmalzried