Tivoli Storage Manager KM for PATROL

Release Notes for v2.7.02

Home  Previous  Next

What's New

TSM-248:Tivoli Storage Manager KM for PATROL  now supports Tivoli Storage Manager Server 7.1.x and Tivoli Storage Manager Administrative Client 6.4.x and 7.1.x, as well as the two operating systems Solaris 11 and Windows 2012.

Changes and Improvements

TSM-204: The query limit for actlogs has been reduced from 1 day to 5 hours. Also, the actlogs query limit can now be user-limited (only available from an actlog instance).
TSM-225: The KM Home Directory path can now be shared when multiple TSM instances are monitored. The KM Temp Directory, KM Debug Directory and DSM Log paths must however remain different (see KB article “Monitoring Multiple IBM Tivoli Storage Manager Server Instances (TSM)).

Fixed Issues

TSM-134: A configuration problem prevented the proper monitoring of different TSM instances through different PATROL Agents on the same TSM server, causing the KM to stop operating.  A procedure is now available in the Knowledge Base of the Sentry’s Web site that describes how to configure the KM in order to monitor multiple IBM Tivoli Storage Manager Server instances.
TSM-141: The TSMLoginStatus parameter triggered false warning when errors from the JOB_TEXT command output occurred.
TSM-142: The product sometimes failed to trigger alerts for missing TSM daemons.
TSM-161 & TSM-168: When activated, the TSMDaemonCollectorExecTime parameter was not appearing in the console under Daemons. Also, an error is displayed on the SOW for the same missing parameter.
TSM-167: When monitoring multiple TSM instances using different PATROL Agents, dsmadmc interface hangs intermittently. The interface access is changed to lock across Agents to avoid simultaneous dsmadmc command executions.
TSM-179: Migration related parameters (TSMPoolSpaceMigrated, TSMPoolSpaceMigratedPercent & TSMPoolSpaceMigrationElapsed) are not available for copy storage pools.
TSM-180: The KM would create unknown job instance (: @ <unknown>) at times, with all offline parameters.
TSM-186: When upgrading the KM to version 2.7.01, custom log filters for alarm and warning were lost.
TSM-188: The KM temporary file system fills up when aclog query grows. To avoid this, a warning message is added to System Output Window (SOW) when any monitored log is not fully processed due to log scan limitation.
TSM-224: On Linux platforms, the commands were randomly corrupted and caused the KM to fail.
TSM-241: The KM custom paths were lost when they were set through PCM and when the PATROL Agent was not restarted immediately after the update.
TSM-269: Due to a PATROL events limitation, the KM failed to trigger log events when a large amount of errors were found in the TSM activity log.
TSM-285: The product failed to identify the creation error for PCM suppressed instances and continued running commands against it, affecting the collector performance.
TSM-291: PATROL Agent was crashing when large actlogs were being processed. To solve this issue, the TSM KM user related activity is no more processed in the actlog. As a consequence, the memory consumption has been reduced.
TSM-297: The KM failed to detect Node Status errors as configured in the KM menu Configuration > Node Status.
TSM-303: The Sudo configuration requirements have been updated in the Security Requirements chapter of the user documentation.
TSM-309: Old TSM jobs were not removed from the console if they were discovered as completed.
TSM-321: Full and incremental domain level backup summary parameters were not set correctly, preventing the product to properly monitor backups at the domain and node levels.
TSM-328: On Windows systems, if the PATROL Agent installation path contained spaces, custom KM scripts and commands with output redirection failed.
TSM-329: The TSMLoginStatus parameter was in warning due to an incorrect configuration variable used while checking the active cluster node.
TSM-330: The Microsoft Cluster active node was not properly detected when the KM was operating in multi-node monitoring mode.
TSM-335: The main discovery cycle was irregular due to an asynchronous default KM discovery interval. It is now reduced to 30 seconds to avoid such irregularity.