Tivoli Storage Manager KM for PATROL

Release Notes for v2.7.00

Home  Previous  Next

What's New

Fully compatible with BMC ProactiveNet Central Monitoring Administration, a feature supported by BMC ProactiveNet Performance Management version 9.0.00.

Now supports Tivoli Storage Manager 6.3 and Microsoft Cluster.

Ability to disable custom events from the KM.

The TSMDaemonCPUUtilization parameter that displays the percentage of CPU consumed by the daemon, was added to the TSM_DAEMON application class.

In order to easily identify which step the initial discovery is processing, the setup icon now reflects the successive phases:

Configuring: this information is only available for BMC ProactiveNet Performance Management

Upgrading: this information is only available for PATROL Classic Console

Loading: indicates that commands are being loaded.

Initializing: indicates that KM paths are being initialized. Missing paths are now specified in the System Output Window

Discovering: indicates that the monitored application is being monitored.

Cleaning: indicates that the temp files are being cleaned

Validating: indicates the application paths are being checked

Changes and Improvements

The KM performance has been improved to support large number Tivoli Storage components.

The performance of the initial job collection cycle has been improved.  A new method was added to enable users to run a PSL command to reduce the duration of the initial job query. 

All previous pconfig variables available under /TSM are now split to /TSM and /Runtime/TSM while upgrading the KM.

<Component>Summary: Duplicate fields in summary text parameters are removed. Only the first entry is kept and all repetitions are ignored even when their values are different.

The job duration calculation method has been improved: job duration/age and job state duration are calculated using the current time instead of job collector start time.

Debug Mode:

The time during which the debug information is logged can now be set by the user.

The KM-related messages that are sent to the System Output Window (SOW) are also logged to the TSM.log file available under <PATROL_HOME>/log.

Logs:The default log scan limit was increased to 500 KBytes.

The delay required to perform a discovery following an Agent restart has been substantially reduced.

All collectors are now automatically refreshed as soon as the KM configuration and the initial discovery are complete.

The default number of instances of Application Classes has been removed. This information must be defined by the user. When set to 0, the monitoring of a specific Application Class is not performed.

Client and PClient policy monitoring is now enabled by default with an instance limit set to 50.

When one or more required paths are missing, the setup instance label will now indicate which paths are missing. A message will also be displayed in the System Output Window.

The TSMRemoveTempFiles parameter was removed since the temporary files are now created and removed by default by the agent user.

Daemons: Non-critical daemons are monitored by default as long as they're alive. No alerts will be triggered when they stop running.

Fixed Issues

Initial Job Collection Cycle: The performance of the initial job collection cycle has been improved. Users can now run a PSL command to reduce the duration of the initial job query.

TSMClientState: This parameter sometimes mistakenly reported a "Never Communicated" status and triggered a false alarm.

TSM Monitoring: TSM could not be monitored when default TSM error log could not be updated by the agent user. The DSMADMC commands issued by the KM have thus been modified to redirect the error logs to the KM temporary folder.

Incorrect management of date/time and elapsed time displayed by the KM for some timezones.

Due to a misinterpretation of the daemon status, the DaemonState parameter was set to "Unknown" while the daemon was actually running.

Debug Mode ZIP output: On Windows 2008, the KM failed to create a ZIP archive with the content of the debug mode.

Monitoring Mode: When the Multi-node mode was activated, the KM failed to distinguish remote nodes with fully qualified hostnames. This issue is now fixed so that the KM menu only requires the PATROL Agent credentials once per remote node.

Node type was not detected on Windows platforms.

Incorrect 'schedule name' in job summary: The DSMADMC command used by the KM for querying job details was changed to support comma delimited text in the field 'reason' and consequently corrected the 'schedule name' .

With some Windows platforms the Debug KM Command was prompting for an OS login to turn the debug on.

The TSMDaemonState parameter was set to "Not Running" when the PATROL Agent could not fork processes, which resulted in invalid alarms on the TSMDaemonStatus parameter.