Version 6.4.1 Release Notes

Platform Support

21556: Collection of BW6 appnode memory metrics
   BW6 Monitor was not collecting all the data for appnodes; specifically memory and
        cpu metrics were missing. This has been corrected. 

Version 6.4.0 Release Notes

Alerts

20858: BW Engine name with spaces now shows in alert message
	The my_alert_actions.sh script (rtvapm/common/bin) failed to process the 
	AlertIndex field correctly if the value contained a space, and would pass "N/A" 
	to subsequent commands. 
	
	For example, a BW alert BWProcessExecutionTimeHigh is executed and the BW Engine 
	name contains a space, "prod.com-Process Archive1". The script sends an email, 
	and in the message the engine name appears as "N/A". 
	
	This has been corrected.

Configuration

21382: History for Tomcat metrics now disabled by default
	Tomcat history has been turned off by default. 
	
	To enable Tomcat history, add the following properties to your sample.properties 
	file: 
	collector.sl.rtview.sub=$TOMCAT_GLOBALREQUESTSTATS_TABLE:TOMCAT_GLOBALREQUESTSTATS 
	collector.sl.rtview.sub=$TOMCAT_WEBMODULESTATS_TABLE:TOMCAT_WEBMODULESTATS
	collector.sl.rtview.sub=$TOMCAT_WEBMODULETOTALS_TABLE:TOMCAT_WEBMODULETOTALS

Data Model

21501: Fixed performance issue due to large list of subs on RtvDisplayServerDisplays cache
	A performance issue from misconfigured history on the RtvDisplayServerDisplays 
	cache has been fixed. 

Deployment

21260: Source column in sender/receiver configuration corrected
	Previously, when BW Monitor dataservers were deployed in sender/receiver mode, 
	the dashboards did not show the correct Source column values. They should reflect 
	the name of the sender dataserver as configured by 
	
	sender.sl.rtview.sub=$rtvAgentName:MyMachineName
	
	but instead the column showed "localhost". 
	
	This has been corrected.

21433: BWAgentPlugin moved to bwmon\agents directory
	The BWAgentPlugin files have been moved from bwmon\lib to 
	bwmon\agents\BWPluginAgent. 

Engines

19233: Engine status now indicated in Engine heatmap drop down list
	BW Monitor displays have been enhanced such that the engine selector dropdown 
	list will show if an engine is not running by appending "(X)" to the entry in the 
	list. 

21263: Total Engine Statistics now displayed on Engine Level
	The BW All Engines Table and Heatmap have been enhanced with the addition of 
	columns giving the total count of created, completed, and aborted processes for 
	each engine. These columns are displayed in the table and in the mouse tooltip in 
	the heatmap 

General

20674: Add jmxconn settings for rtview servers pages
	The jmx connections specified for connecting to RTView Server JVMs have been 
	moved from rtvapm.bwmon.properties into a new file bwmon_jvm.properties, which is 
	now called from the standalone rtvservers.dat. 
	
	This will prevent an EM collector from incorrectly trying to connect to these 
	servers. 

20764: Checkboxes to control labels added to BW Monitor heatmaps
	In the BW Monitor heatmap displays for Engines, Processes, and Activities, the 
	slider which controlled the visibility of the heatmap labels has been replaced 
	with checkboxes, following the standard for EM displays. 

21290: New Alerts and key metrics for correlating process activity vs. resources
	BW Monitor has been enhanced with new alerts and new Key Metrics.
	
	The following new alerts have been added:
	
	Name                             Metric
	----                             ------
	BwProcessAvgExecutionTimeHigh    AverageExecution    
	BwProcessAvgElapsedTimeHigh      AverageElapsed
	BwProcessCreatedRateLow          RateCreated
	BwProcessCreatedRateHigh         RateCreated
	BwProcessTotalCpuPercentHigh     TotalCpuPercent
	
	
	For EM users, the following new Key Metrics have been added to the BW-PROCESS CI 
	Type: 
	
	
	Name                         Alert
	----                         -----
	Process Avg Elapsed Time     BwProcessAvgElapsedTimeHigh
	Processes Created / sec      BwProcessCreatedRateHigh
	Process Total CPU Percent    BwProcessTotalCpuPercentHigh

21409: Added AvgElapsedTime, AvgExecTime, and TotalCpuPercent to BwProcesses cache
	The BW Process metrics Average Execution and AverageElapsed are now calculated by 
	dividing the delta execution or elapsed time for the interval by the delta 
	completed, or the number of process instances that completed in the interval. 
	
	Previously they were calculated by dividing the total execution or elapsed time 
	by the total number of process instanced (over all time). 
	
	Users will need to update the table structure of the BW_PROCESSES historian 
	tableby executing the following alter table SQL sentences in your selected 
	database administrative tool: 
	
	DB2:
		
	ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT;
	ALTER TABLE "BW_PROCESSES" ADD "AverageElapsed" BIGINT;
	ALTER TABLE "BW_PROCESSES" ADD "TotalCpuPercent" DOUBLE;
		
	SQL Server:
		
	ALTER TABLE [BW_PROCESSES] ADD [AverageExecution] BIGINT;
	ALTER TABLE [BW_PROCESSES] ADD [AverageElapsed] BIGINT;
	ALTER TABLE [BW_PROCESSES] ADD [TotalCpuPercent] FLOAT;
		
	MySQL:
		
	ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT;
	ALTER TABLE "BW_PROCESSES" ADD "AverageElapsed" BIGINT;
	ALTER TABLE "BW_PROCESSES" ADD "TotalCpuPercent" DOUBLE;
		
	Oracle:
		
	ALTER TABLE "BW_PROCESSES" ADD ("AverageExecution" NUMBER, "AverageElapsed" 
	NUMBER, "TotalCpuPercent" REAL); 
	
	SyBase:
		
	ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT NULL, "AverageElapsed" 
	BIGINT NULL, "TotalCpuPercent" FLOAT NULL; 

21410: Enhancements to Activity metrics on Process displays
	The trends on the BW Process Summary page have been enhanced as follows:
	
	The Process Elapsed/Exec Time per Sec trends have been replaced with Average 
	Elapsed and Execution Time trends. A Total CPU Percent trend has been added. The 
	"All Activities Exec Count and Time" trends have been removed. 
	
	The BW All Processes table has also been enhanced as follows:
	
	A Total CPU Percent column has been added, and the columns have been rearranged 
	to put the Key Metrics among the first columns displayed. 

21411: Implement filter-in and filter-out patterns for process cache
	The BwProcess cache has been enhanced with the ability to filter the processes by 
	name using regular expressions before they are added to the cache. 
	
	Two filter expressions may be set by using new properties in sample.properties. 
	Each property specifies a regular expression which will be applied to the process 
	name. If the name matches the pattern the process will be included. 
	
	To exclude processes, start the filter pattern with "^" (negation).
	 
	collector.sl.rtview.sub=$bwprocessFilterPattern:''
	collector.sl.rtview.sub=$bwprocessFilterPattern2:''
	
	For example, say you have these processes:
	
	process01.process
	process02.process
	process03.process
	process04.process
	process05.process
	process06.process
	process07.process
	
	If you set the first property as follows:
	
	collector.sl.rtview.sub=$bwprocessFilterPattern:'0[3-5]'
	
	you will get:
	
	process03.process
	process04.process
	process05.process
	
	If you set the second property as follows:
	
	collector.sl.rtview.sub=$bwprocessFilterPattern:'0[^4]'
	
	you will get, finally:
	
	process03.process
	process05.process

21486: New option to use cross-platform fonts
	When the Display Server is running from a host operating system other than the 
	operating system of the client browsers, label alignment inconsistencies can 
	occur due to font unavailability. This is especially pronounced for a Linux 
	server and WIndows client scenario. 
	
	RTView EM now provides a rtvapm/rtview/lib/rtvfonts.jar that can be enabled in 
	the Display Server, so that the client browser will download the fonts used by 
	the server. 
	
	To enable this option, which is recommended for linux hosts, edit
	rtvapm/common/conf/rtvapm.properties and uncomment the following two lines:
	
	#sl.rtview.cp=%RTV_HOME%/lib/rtvfonts.jar
	#sl.rtview.global=rtv_fonts.rtv

Monitor

21134: The date picker no longer generates incomplete date format.
	In previous releases, the date chooser dialog in the trend graph views did not 
	set the end time correctly for servers that were not in the same time zone as the 
	client. This has been fixed. 

RTView Core Functionality

Data Historian

19992: New Smooth Compaction configuration options
	New arguments have been added to customize how compaction smoothing is performed.
	
	 -smoothingonly 
	Run smoothing only without data being provided
	
	-smoothcompaction:table1,table2
	Restrict the tables being smoothed to those specified

21455: New mechanism to 'throttle' historian deletions.
	A command line argument has been provided to enable throttling of historian 
	deletions by separating large deletions into smaller groupings. This option will 
	help in scenarios where users see the following errors in the log: 
	
	   SQLException: The transaction log for database <DB Name> is full.
	ERROR: java.sql.SQLException: The transaction log for database <DB Name> is full. 
	retention doing delete in SQL: [delete from <DB Table Name> where "timestamp" < 
	'YYYY-MM-DD HH:MM:SS'] failed. 
	
	To enable multi-chunk retention start the historian with the -retentionChunkSize 
	argument. 
	
	Example of deleting in 2 day chunks:
	-retentionChunkSize:2d  
	
	Example of deleting in 1 week chunks:
	-retentionChunkSize:1w
	
	This argument does not support time segments of multiple units, such as "1h 30m"

Data Server

20910: RTVquery no longer hangs when the target data server re-boots
	In previous releases, the rtvquery servlet would occasionally fail to respond to 
	queries after its target data server was restarted. This problem is fixed 

Data Sources

18403: Fixed cache bug with maxNumberOfCurrentRows and blank timestampColumnName
	The cache data source no longer throws a NullPointerException if a cache has 
	maxNumberOfCurrentRows > 0 and a blank timestampColumnName. 

20692: Fixed bogus timeout of sql query
	A problem has been fixed in the SQL datasource which would sometimes cause a 
	query to fail with a bogus timeout error showing a very large and incorrect 
	timeout value. 

20767: xml parser no longer throws exception if token >= 8192 chars
	In previous releases, the JMS and XML data sources would throw an 
	ArrayIndexOutOfBoundsException if an XML string token contained 8192 or more 
	characters and none of those characters was a space. This is fixed. 

21299: Improved hawk error handling
	The TIBCO Hawk data source error handling has been enhanced as follows:
	
	1. Improved logging for onErrorExceptionEvent and onWarningExceptionEvent. These 
	events occur when there is a problem with one of the connected TIBCO Hawk 
	Transports. Also, RTView will now try reconnecting to the transport if an 
	onErrorExceptionEvent occurs. 
	
	2. Improved logging for subscription error events. Also, RTView will cancel all 
	subscriptions for a MicroAgent if an onTermination event occurs and attempt to 
	recreate them. 

21392: New reconnect option added to Hawk DS
	The TIBCO Hawk data source has been enhanced to attempt to reconnect when the 
	initial connection to a transport fails. By default, it will attempt to reconnect 
	once a minute for 60 attempts. You can set the max number of reconnect attempts 
	by command line or property. 
	
	command line: -hawkmaxreconnect:3
	property: sl.rtview.hawk.hawkmaxreconnect=3
	
	Every time a reconnect is attempted, you will see this in the console:
	016-03-07 13:00:50.282 re-attempt connection to transport <test_ems>: 1 of 60
	016-03-07 13:00:52.911 re-attempt connection to transport <test_ems>: 
	succeeded/failed 
	
	To disable reconnection attempts, set the max reconnect to 0.

Display Server

19512: Support audio and threshold command in thin client
	The thin client now supports the Play Audio File command and threshold commands. 
	In addition, a new property named valueCommandResetTrigger has been added to the 
	display objects that support threshold commands. 
	
	-------------------
	Play Audio File command:
	
	The thin client now supports the Play Audio File command. The support for audio 
	file formats varies by platform, as follows. 
	
	- The Play Audio File command is not supported in Internet Explorer version 8 and 
	older. 
	- In a desktop browser (Internet Explorer 9 or newer, Firefox, Chrome) .wav and 
	.mp3 files are supported. However, Internet Explorer uses the Windows Media 
	Player to play .wav files, which may require user confirmation or may fail due to 
	security settings. 
	- In mobile browsers (e.g. Safari on iOS) only .mp3 files are supported, and the 
	user must click on the "Enable Audio" button that appears in a display the first 
	time an audio command is executed. 
	- The "Beep" command is still not supported in the thin client. 
	
	Note that in the builder/viewer, only .wav files are supported by the Play Audio 
	File command. This has always been the case and has not changed in this release. 
	
	---------------------
	Threshold command:
	
	There are four objects that support threshold commands: obj_circ2d_ilvx_ra4, 
	obj_rect_ilvx_ra4, obj_circ2d_ilvx_da3, and obj_rect_ilvx_da3. A threshold 
	command can be defined using any of the properties named value*Command on those 
	objects. 
	
	In this release, if the webChartFlag property is checked on an object with a 
	threshold command, the threshold command will be executed in a thin client 
	deployment when appropriate. In prior releases, threshold commands were ignored 
	in a thin client deployment. 
	
	If the threshold command is a supported client-side command it will be executed 
	in the browser. The client-side commands are: Play Audio File, Drilldown/Set 
	substitution, Execute Custom Command (if the custom command has a javascript 
	implementation), Open Browser. All other commands are executed by the display 
	server or (for a data source command) in the data server. 
	
	A new property named valueCommandResetTrigger was added to the objects that 
	support threshold commands. Typically, once a threshold command has been executed 
	by one of those objects because the value exceeds or equals a limit, the command 
	will not execute again until the value exceeds another limit. But now, if the 
	value of valueCommandResetTrigger property is changed, then the object's 
	threshold command will be executed again even if the value property has not 
	changed. Changing the value of valueCommandResetTrigger when the object's value 
	is not at or above a limit has no effect. 

20679: Table row selection in AW grid no longer unreliable in IE >= 10
	In previous releases, when using the thin client in IE 10 and 11, after 
	performing a drilldown from a table object subsequent row clicks in the same 
	table may be ignored. This is fixed. 

21435: Mouse wheel scrolling for tables when using Firefox 42 or newer
	In prior releases, the thin client did not support scrolling of table objects 
	using the mouse wheel, if webGridFlag = false, in Firefox version 42 or newer. 
	This is fixed. 

General

20326: New -version flag that prints version information without starting the app
	Each of the RTView applications now supports a -version option on the command 
	line which will cause the app to print the RTView version information and then 
	exit immediately. 
	
	For example:
	
	run_dataserver -version

Logging

19543: Alert notification script output error when using log4j
	Alert notifications from an RTView now go to a log4j output as desired.

Object Library

19936: Added support for data quality to obj_statushistory
	The status history chart (obj_statushistory) has been enhanced to indicate data 
	quality. 
	
	Two new properties have been added, named valueQualityColumnName and 
	valueQualityBadValuesList. These properties can be used to set a color and 
	pattern to be plotted when on a bar when the data quality is bad. 
	
	The valueQualityColumnName property can be set to the name of the table column 
	that contains a value indicating the data quality for each row. The column can 
	contain string, integer, or boolean values. The valueQualityBadValuesList 
	property can be set to a string containing value,label pairs with each pair 
	separated by semicolons. This is used to assign a label to a numeric bad quality 
	value, for example "-1,no data;0,stale data" 
	
	The default value for valueQualityColumnName is blank, which means that the new 
	feature is disabled. In this mode the color and pattern for each bar is 
	determined by getting the value for that row from the column specified by 
	valueColumnName, and looking up that value in the chart's barProperties. (This is 
	the behavior in all prior releases). 
	
	If valueQualityColumnName non-blank, then for each row R the row's value to be 
	plotted is determined as follows: 
	
	- let Q = value of quality column for row R, and V = value of value column for 
	row R 
	- if Q is blank, then the quality is considered good and V is used at the row 
	value, as normal. 
	- else if the valueQualityBadValuesList property is blank, then Q is used as the 
	row value. 
	- else if valueQualityBadValuesList contains an entry "Q,X" then X is used as the 
	row value 
	- else the quality is considered good (since no match was found in 
	valueQualityBadValuesList) and V is used at the row value 
	
	Then the row value is looked up in barProperties, as usual, to determine the 
	color and fill pattern. That value is also shown in the mouseover text as usual. 
	
	For example, consider the following data table:
	
	 Plant	Status	Quality
	 -----	------	-------
	 A	online	   1
	 B	offline	   1
	 C	online	  -1
	 D	offline	   0
	
	... where 1 = data OK, -1 = no data, and 0 = stale data.
	
	Next, consider a status history chart with these properties:
	
	 indexColumnNames = Plant
	 valueColumnName = Status
	 valueQualityColumnName = Quality
	 valueQualityBadValuesList = -1,no Data;0,stale data
	 barProperties = 
		online  : green
		offline : blue
		no data : red
		stale data : orange
	
	Note that valueQualityBadValuesList has no entry for quality = 1, because that is 
	the "good" quality value. 
	
	With that configuration, when the data table shown above is applied to the chart, 
	it will plot a segment for each Plant as follows: 
	
	A  green   (since Status = online and Quality = 1 / OK)
	B  blue    (since Status = online and Quality = 1 / OK)
	C  red     (since Quality = -1 / no data)
	D  orange  (since Quality = 0 / stale data)

20996: Enable copy to clipboard on multiselect Kendo grid
	The text in selected row or rows of the web (kendo) grid can now be copied to the 
	clipboard by pressing Ctrl+c when the grid has keyboard focus. 
	
	Only text cells are copied. If a cell contains an image, its value is not copied 
	to the clipboard. The grid must have keyboard focus for the Ctrl+c keystroke to 
	have effect. 

Platform Support

19925: Support Java 1.8
	Java 1.8 is now officially supported. 
	
	NOTES: 
	As noted in the release notes for 19927 and 19928, the JdbcOdbc driver is no 
	longer supported by Oracle beginning in Java 1.8. 
	
	Version v4.14.137 of IBM DB2's db2jcc.jar driver is required to work with Java 
	1.8 

21076: Windows 10 and Edge Browser support
	Windows 10 and the Edge Browser are now supported by RTView products.

Security

20794: Fixed XSS Security Issue in Thin Client Deployment
	A cross-site scripting (XSS) vulnerability in the thin client has been fixed.

21179: Check column names in servlet URL for code injection attacks
	The rtvquery servlet will now encode any < or > characters that appear in the 
	"cols" parameter as < and > in the response, to avoid possible XSS hacks. 

Scripts

19498: Fixed error in script update_wars_package.sh
	The shell script rtvapm/common/bin/update_wars_package.sh used the Linux rename 
	utility which does not exist on some versions of UNIX. This has been corrected. 

20961: start_rtv.sh, status_rtv.sh and stop_rtv.sh corrected for Mac
	On Macintosh systems the start_rtv.sh script would give the error "command not 
	found" when trying to start a server. this has been fixed. 

21051: RTView Processes now named in greater detail
	When an Rtview process is launched it is given a Java argument of the form 
	-DPROCESS_NAME=xxx. Previously the value "xxx" was a generic tag such as 
	"dataserver". Now this will specifically identify the process by constructing a 
	tag from the line in rtvservers.dat used to launch the process. 
	
	The tag will be of the form {config name}_{server name}_{server JMX port}. For 
	example, the server "AlertServer" in the config "central" will be given the tag 
	central_AlertServer_10023. 
	
	This can be seen on Unix with ps: 
	
	 > ps -ef | grep java 
	
	m 19558 1 0 06:29 pts/2 00:00:00 java -DPROCESS_NAME=central_AlertServer_10023 
	-DRTV_HOME=/u/rtvdemos/rtvapm/rtview 
	-DRTV_DEMOSERVER=/u/rtvdemos/rtvapm/rtview/servers/apache-tomcat-6.0.18-sl 
	-Xmx256m -Xms128m 
	-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager 
	. . . 
	
	 Or with jps (if available): 
	
	 > jps -vV 
	
	19558 RTViewDataServer -DPROCESS_NAME=central_AlertServer_10023 
	-DRTV_HOME=/u/rtvdemos/rtvapm/rtview 
	-DRTV_DEMOSERVER=/u/rtvdemos/rtvapm/rtview/servers/apache-tomcat-6.0.18-sl 
	-Xmx256m -Xms128m 
	-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager 

21278: status_rtv.bat on Windows again shows Uptime, CPU, Heap
	On Windows the status_rtv.bat script, while listing running dataservers, was 
	omitting the JMX info (e.g. Uptime 000:00:00:46 CPU 00:00:24 Heap 3.6% ...) 
	
	This has been fixed.

Solution Package

TIBCO Hawk

21390: New hawk debug caches added to hawkmon
	The hawkmon package (included in bwmon and amxmon) has been enhanced with new 
	caches that will assist in debugging problems with Tibco Hawk agents. The new 
	caches are: 
	
	HawkAgentStatus - This contains one row for each Hawk agent and shows the status 
	of that agent. 
	HawkConnections - This contains one row for each hawkconsole property line and 
	shows the status of that connection. 

Version 6.3.0 Release Notes

Alerts

20113: New BwProcessElapsedTImeHigh alert
	A new alert has been added: BwProcessElapsedTimeHigh.
	
	This is driven by the metric RateTotalElapsed in the BwProcesses table.

BW Platform Support

20702: BW6 Support
	The BW solution has been enhanced with the ability to monitor TIBCO ActiveMatrix 
	BusinessWorks 6 Applications and AppNodes. The BW6 solution displays show current 
	and historical resource usage and error states across BW Applications and down to 
	the level of BW Processes and Activities. 
	
	RTView Alerts are implemented on key metrics at the Application, AppNode, and 
	Process levels and are incorporated into the displays. 
	
	The following displays are added to the navigation tree of the standalone 
	solution: 
	
	BW6 Applications
	  All Applications Heatmap
	  All Applications Table
	  Single Application Summary
	  
	BW6 AppNodes
	  All AppNodes Heatmap
	  All AppNodes Table
	  Single AppNode Summary
	
	BW6 AppSlices
	  All AppSlices Heatmap
	  All AppSlices Table
	  Single AppSlice Summary
	
	BW6 Processes
	  All Processes Heatmap
	  All Processes Table
	  Single Process Summary
	  
	BW6 Hosts
	  All Hosts Heatmap
	  All Hosts Table
	
	
	The layout of the displays follows RTView standards and is similar to BW(5)mon. 
	In each section of the tree the table view shows all the data, allowing for 
	filtering, and the heatmap allows you to select the metric for the color scale. 
	The summary views show current and historical metrics for a single instance. 
	
	Process and Activity metrics are essentially unchanged from BW(5) and AppNode 
	metrics are similar to BW(5) Engine metrics. BW6mon adds the viewpoint of 
	Application and AppSpace. Process metrics, including such things as creation and 
	completion, exec and elapsed times, are summarized for the application and also 
	for each slice of the application on multiple appnodes. Specifically: 
	
	BW6 Applications
	Shows Applications and AppSpaces across BW6 Domains with Process metrics totaled 
	by Application. 
	The summary display also shows the AppNodes of the deployment and Process metrics 
	totaled by AppNode. This is useful to see the deployment and load balancing of 
	the Application in current and historical time. 
	  
	BW6 AppNodes
	Shows ApppNodes and their resource usage in terms of internal JVM memory and host 
	CPU. This is useful because the AppNode performance is dependent on both internal 
	and external factors and sometimes they interact. 
	
	BW6 AppSlices
	The AppSlice is the part of an Application running on a specific AppNode when the 
	Application is deployed to multiple AppNodes. These displays show process metrics 
	totaled by Application and AppNode. this is useful to see how the application is 
	distributed and how each part of it is peforming. 
	
	BW6 Processes
	Very similar to the BW(5) Process metrics, including the addition of Delta and 
	Rate columns for many metrics. These displays are useful for a closer look at the 
	performance and resource usage of specific Processes in the Application. 
	  
	BW6 Hosts
	These displays show the health and history of the host systems running the 
	AppNodes. 
	  
	BW6mon can be installed along with BW(5)mon and an RTView data server can include 
	one or the other or both according to the user's configuration. The configuration 
	is similar to BW(5)mon, using Hawk for data collection. 
	
	
	===========================
	Limitations in this release:
	===========================
	
	TIBCO ActiveMatrix BusinessWorks 6.2.1 has issues with the Hawk microagent that 
	impose the following limitations on BW Monitor. 
	
	(1) Activity statistics are not completely implemented in Hawk. Activity-level 
	metrics and displays are not available in this release of BW Monitor. 
	
	(2) Process statistics are not completely implemented in Hawk. Min/Max/Average 
	Elapsed Time will be zero. 
	
	(3) Some statistics are not implemented in Hawk on Windows. This release of 
	BW6mon does not support TIBCO ActiveMatrix BusinessWorks 6 on Windows. 
	
	(4) The bwadmin command "enablestats" command does not enable statistics in the 
	Hawk microagent. You must enable process statistics for your BW6 applications via 
	hawk, e.g. using the Hawk Display tool. 

Data Historian

20218: Accuracy of BW Process columns improved
	The data types of Active and DeltaCreated columns in the BW_PROCESSES table have 
	been converted to real numbers to account for the loss of resolution when 
	compaction is taking place by averaging the metrics. 
	
	As part of upgrading you must use alter table SQL like provided below for your 
	supported DB platform (Oracle not required). 
	
	DB2:
	
	ALTER TABLE "BW_PROCESSES" 
	ALTER COLUMN "Active" SET DATA TYPE DOUBLE;
	ALTER TABLE "BW_PROCESSES" 
	ALTER COLUMN "DeltaCreated" SET DATA TYPE DOUBLE;
	
	ALTER TABLE "BW_PROCESS_TOTALS"
	ALTER COLUMN "Active" SET DATA TYPE DOUBLE;
	
	
	SQL Server:
	
	ALTER TABLE [BW_PROCESSES]
	ALTER COLUMN [Active] FLOAT
	ALTER TABLE [BW_PROCESSES]
	ALTER COLUMN [DeltaCreated] FLOAT
	
	ALTER TABLE [BW_PROCESS_TOTALS]
	ALTER COLUMN [Active] FLOAT
	
	
	MySQL:
	
	ALTER TABLE "BW_PROCESSES" 
		MODIFY "Active" DOUBLE , 
		MODIFY "DeltaCreated" DOUBLE ;
	
	ALTER TABLE "BW_PROCESS_TOTALS" 
		MODIFY "Active" DOUBLE ;
	
	
	SyBase:
	Altering the data type of columns in a Sybase table requires enabling the “select 
	into” option for your database. Consult with your DB Admin on the correct 
	procedure for your installation. 
	
	ALTER TABLE "BW_PROCESSES" MODIFY "Active" FLOAT
	ALTER TABLE "BW_PROCESSES" MODIFY "DeltaCreated" FLOAT
	
	ALTER TABLE "BW_PROCESS_TOTALS" MODIFY "Active" FLOAT

Engines

19293: Cleaned up incorrect symbols appear in Heatmap mouseover
	NaN special-character symbols have been replaced in the mouse over of All Engines 
	Heatmap display with a 0 value. 

General

19961: BW Engine heatmap box size adjusted to accomodate outliers
	In previous versions, the heatmap on the "BW Engine Summary" screen would fail to 
	show a box for each process in certain cases. The box size was proportional to 
	the number of process instances that had been created for a given process. Hence, 
	boxes would be missing when either 
	a) one process creation count was so large that it crowded out the other process 
	creation values, or 
	b) one or more processes had a zero creation count.
	The box size is now proportional to the log(+1) of the creation count, so a box 
	should now be visible in all cases to support visualization and drill-down. 

20143: Improved resize behavior of top-level common selectors
	The resize behavior of the Activity displays has been improved so there will be 
	more room to show the Process and Activity names as the display is resized. 

20616: Odd square shape drawn atop center ListBoxes of "Single BW Activity Summary"
	Under some circumstances the BW Monitor Activity Summary display would show some 
	extraneous objects when displayed in the thin client. These objects are small 
	rectangles (about 4 X 2 pixels) drawn on top of the selector combo boxes. This 
	has been fixed. 

20759: Removed “Invalid column name” startup errors
	When BW Monitor would start up the following messages would appear one time in 
	the log. 
	
	<bwProcessDefinitionDataUnix41>, Invalid column name
	<bwProcessDefinitionDataWin41>, Invalid column name
	
	This did not indicate a problem and the messages have been removed.

JVM metrics

20229: JVM Memory data no longer gaps in trends received from sender
	A bug that prevented correct visualization of Memory in the JVM Summary display 
	has been fixed. 

Monitor

20537: New properties to limit Display Server table cells
	The Monitor has been enhanced to support 3 new properties to limit the amount of 
	data that is passed from the Display Server to the browser for tables. The 
	following properties have been added to common\conf\rtvapm.properties: 
	
	cellsperpage - This limits the number of cells (columns*rows) that will be 
	displayed in a table object. This avoids the sluggish performance, timeouts, 
	and out-of-memory exceptions that might otherwise occur from processing and 
	transmitting all of the rows at once Table objects with more than the specified 
	number of cells are paged. This means that the Display Server only sends the rows 
	that are visible plus a few rows before and after the visible rows. As the user 
	scrolls, the new rows are requested from the Display Server. This results in a 
	small delay between the scroll action and the data showing up in the table. The 
	default is 20000. 
	
	cellsperexport - This limits the number of cells (columns*rows) that will be 
	exported for the Export to Excel and Export to HTML operations. The default is 
	40000. 
	
	cellsperreport - This limits the number of cells (columns*rows) that will be 
	exported for the Export to PDF operation. The default is 20000. 
	
	For all of the new properties, a value of less than 1000 will disable the 
	property. Values larger than the defaults may result in slower performance, 
	timeouts and/or out-of-memory exceptions when interacting with tables in displays 
	in the thin client. 

Platform Support

20536: Support added for Red Hat Linux 7
	RHEL 7 is now a supported platform for RTView.
	

RTVMGR

19472: New Version Info display added to rtvmgr
	The RTVMGR has been enhanced with a new RtvServerVersions cache and Version Info 
	page. The information in this cache and display is useful when reporting problems 
	to SL Technical Support as it contains very detailed information about the 
	version of each jar used in each connected RTView application. 
	
	The Version Info display is accessible from the navigation tree under RTView 
	Servers->Version Info or from the About display. The table contains one row for 
	each RTView jar in each RTView application for which the RTVMGR has a jmx 
	connection defined. This display combines the values for all connected RTVMGR 
	data servers. 
	
	The table contains the following columns:
	
	Source: The name of the RTVMGR source. 
	Connection: The name of the jmx connection to the RTView application.
	ApplicationName - The name of the application. Ex.RTView Data Server.
	ApplicationConfiguration - The configuration string for the application. This 
	string contains the main application version that corresponds to the version 
	information that is printed to the console at startup. 
	JarName - The name of the jar. 
	JarConfiguration- The configuration string for the jar. 
	JarVersionNumber - The version number for the jar.
	JarVersionDate - The version name for the jar.
	JarReleaseType - The release type for the jar.
	JarMicroVersion - The micro version for the jar.
	Expired - True if the row in the RtvServerVersions cache has expired. The 
	expiration is set by the $jvmRowExpirationTime substitution. 
	time_stamp - The timestamp when this information was last received. This data is 
	queried once a minute. 
	DataServerName - The name of the RTVMGR data server connection.
	
	Rows where the JarConfiguration does not match the ApplicationConfiguration are 
	highlighted in teal. RTView applications running versions previous to this 
	enhancement will only have one row in the table and will say "version info not 
	support in this version" in the ApplicationConfiguration column. 
	
	Filter the table using the controls at the top of the display:
	
	Source: Select a value to filter on the Source column
	Connection: Select a value to filter on the Connection column
	Filter Field: Select an additional column to filter on
	Filter Value: Enter a value to filter on in the Filter Field column
	Use RegEx: Set to true to use the Filter Value as a regular expression when 
	filtering 
	Not Equals: Set to true to show rows where the Filter Field value does not match 
	the Filter Value. This is only available if Use RegEx is selected. 
	Clear: Clears the Filter Field, Filter Value and Not Equals.

20108: New alerts TomcatActiveSessionsHigh and TomcatAppActiveSessionsHigh
	Two new Tomcat alerts, TomcatActiveSessionsHigh and TomcatAppActiveSessionsHigh, 
	have been added to alert when the number of active sessions of a Tomcat Server 
	and a Tomcat Application reach their thresholds. 

20183: JVM Operating System Cache no longer shows PhysicalMemory = 0
	A bug that prevented the JvmOperatingSystem cache from correctly collecting the 
	TotalPhysicalMemory metric has been fixed. 

20190: New Jvm Thread Count High alert
	A new alert, JvmThreadCountHigh, has been added. This alert fires when the number 
	of threads exceeds the established thresholds. 

20214: Process Name and PID added to Data Server display
	The RTView Data Server metrics display has been enhanced to include Process Name 
	and PID columns in the Data Server Clients table. 
	
	The value that appears in the Process Name column depends on the type of client. 
	If the client is an RTView application, then the Process Name shows the value of 
	the PROCESS_NAME property when the app was started. If the client process was 
	started with a standard RTView script (e.g. run_viewer, run_displayserver, etc) 
	then the Process Name will be viewer, builder, dataserver, displayserver, or 
	historian. For a server, a "d" at the end of the process name indicates it was 
	started with the -daemon option. If the PROCESS_NAME property was undefined when 
	the client process was started, then the Process Name will be RTView (the 
	viewer), RTView Display Builder, Display Server, Data Server, or Historian, or 
	the OEM names assigned to those applications. If the client is the viewer applet, 
	then "applet" is appended to the name. 
	
	If the client is the rtvdata or rtvquery servlet, the Process Name will be 
	RTVDataServlet and rtvquery, respectively, or the custom servlet name that has 
	been configured for the deployed servlet instance. 
	
	The PID column shows the PID (process ID) of the client process. Typically the 
	PID column value will appear as nnnn@hostname, where nnnn is the PID from the 
	client's host system (as reported by jps, top, or tasklist) and hostname is the 
	name of the client's host. If the client is the rtvdata or rtvquery servlet, then 
	the PID will correspond to the app server (e.g. tomcat) process on the client 
	host. The PID column may be blank if the client is unable to obtain its PID from 
	the local operating system. The @hostname portion may be omitted if it cannot be 
	obtained from the local operating system. 
	
	The PID and Process Name columns will both be blank if the client process is 
	running an older version of RTView that does not have this enhancement. 

20574: Fixed "tomcatManagerStats77DeltaRate" function error
	Previously the message "ERROR: function <tomcatManagerStats77DeltaRate>, Invalid 
	(non-numeric) data column" would appear when Tomcat connections were not present. 
	This has been fixed 

RTView Core Functionality

20643: New option to restrict number of characters in alert comments in the alert ds
	The Alert data source has been enhanced with a new Maximum Characters Allowed in 
	Comments Field property to limit the number of characters it will store in the 
	Comments field. In previous releases, new comments were appended to the existing 
	contents of the Comments field with no limit on the amount of text. This caused 
	problems for alert persistence and alert history if the Comment field became 
	longer than corresponding database field could handle. 
	
	For this enhancement, the order of the comments has been reversed so that new 
	comments are added before existing contents in the Comments field. If the Maximum 
	Characters Allowed in Comments Field is greater than 0 and a new comment is added 
	to an alert, the content of the Comments field will be trimmed by removing 
	characters from the end of the contents if necessary to stay under the limit. 
	
	By default, this feature is disabled and the Comments field will grow unbounded 
	as new comments are added. To enable the limit, set the Maximum Characters 
	Allowed in Comments Field in the Alerts tab of the Application Options dialog to 
	a value greater than 0. You can set it using the following property: 
	
	sl.rtview.alert.commentlimit
	
	This comment limit is be available via a data attachment to alert-commentlimit to 
	facilitate building a UI that will prevent users to enter comments longer than 
	this limit. Note that the UI text entry limit should be set to 100 characters 
	less than the comment limit in order to account for the time stamp, user name and 
	hard returns between comments. 
	
	Persisted alerts with comments from a previous versions will have mixed order on 
	the Comments contents. It will be oldest->newest for persisted comments, then 
	newest->oldest for new comments added in this and later releases. Persisted 
	comments from previous versions that have been persisted and are longer than the 
	specified Maximum Characters Allowed in Comments Field will be trimmed on 
	startup. 

Alerts

20664: New option to exit if alert persistence is enabled but database table is unavailable
	The Alert data source has been enhanced with a new property:
	
	sl.rtview.alert.exitOnPersistInitFailed
	
	This property controls what happens when alert persistence is enabled but cannot 
	be initialized due to a database problem or configuration issue. When 
	exitOnPersistInitFailed is set to false (default), RTView will initialize the 
	alerts with persistence disabled. This is the behavior in previous releases. When 
	exitOnPersistInitFailed is set to true, RTView will exit after the persistence 
	initialization has failed without initializing the alerts. 

Commands

19854: Email command no longer garbles Japanese chars in name of attached file
	The Send Email command no longer garbles Japanese and other non-ascii characters 
	in the names of files attached to an email. 

Data Historian

20019: Compaction smoothing no longer sets incorrect "run after" date
	Previously, the smooth compaction option caused an an incorrect "run after" date 
	to be set for further compaction. This could result in a small portion of data 
	not being compacted. This has been fixed. 

20067: Data retention (purging) now correctly performed after compaction/smoothing
	Previously, database retention logic was incorrectly postponed after 
	smoothing/compaction had taken place on a table. This could result in the 
	retention of more data than specified in historian configuration. This has been 
	fixed. 

20159: Sync up data from the history cache when historian starts
	The Historian supports a new option named persistInitTimeRange which affects the 
	cache persistence feature. 
	
	Normally, when the cache persistence feature is enabled in the historian, the 
	historian begins collecting cache history data starting at the time when each 
	data server connects. This is adequate in most situations. The 
	persistInitTimeRange option can be used to specify a time range, in seconds, back 
	from the current time that the historian should get cache history data from the 
	data server. This can be useful if the historian is started sometime after the 
	data server, so the data server has collected cache history that hasn't been sent 
	to the historian. For example, if the data server was started an hour before the 
	historian, then the historian could be started as follows, so that it will 
	request an hour of cache history from the data server: 
	
	   run_historian -persistCaches:true -persistInitTimeRange:3600

20187: Option to perform compaction for a time range prior to "now"
	An option was added to the Historian to allow for the smoothing process to only 
	go back as far as a specified range in the form: 
	
	     -smoothCompactionRecent:NN Where NN is '1d' or '1w'

20254: Retention-only compaction now executed correctly
	Previously the historian would fail to run compaction if the Compaction Rules 
	consisted of a single rule that only specified a duration of Raw data (-). 
	
	This has been fixed.

20637: New option to limit length of strings from cache table stored in db
	The historian has been enhanced to support a limit on the length of a string from 
	a cache table column that it will store in the database. If a string is longer 
	than the specified limit, it will be truncated to the limit before it is stored 
	in the database table. This can avoid SQL exceptions encountered when the length 
	of a string exceeds the capacity of the column's data type (for example, 4000 
	characters in an VARCHAR2 column in Oracle). 
	
	The limit is specified by a new property named stringColMaxLen. This can be 
	specified in HISTORY.ini as follows: 
	
	stringColMaxLen 3500
	
	It can also be specified on the command line or a properties file. By default the 
	property has no value, so no limit is enforced. 

Data Server

20596: Fixed duplication in connection error messages
	A bug has been fixed which caused duplication of log messages when a client lost 
	its connection to a data server. 

Data Sources

19563: -sqltryodbc:false is now the default RTView behavior
	By default, the SQL data source will no longer attempt to make an ODBC connection 
	to XYZ if an sql query or command is executed that references a database XYZ but 
	there is no definition of XYZ in OPTIONS.ini. Instead the following error message 
	will appear in the console: 
	
	   Undefined SQL database XYZ
	
	To force the SQL data source to attempt an ODBC connection when an undefined 
	database is referenced as in prior releases, specify the following command-line 
	options: 
	
	-sqltryodbc:true
	
	The option can also be specified in OPTIONS.ini:
	
	sqltryodbc true
	
	or in a properties file:
	
	sl.rtview.sql.sqltryodbc=true
	
	Note that RTView will still make an ODBC connection to database XYZ if it appears 
	in OPTIONS.ini with the odbc driver specified, regardless of the -sqltrodbc 
	option. 
	
	However, note that the ODBC driver is not supported in Java 1.8 or newer. If an 
	ODBC connection is attempted in java 1.8 or newer, the following error messages 
	will appear in the console: 
	
	ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver (ODBC driver is not 
	available in Java 1.8 or newer) 
	   Unable to connect to database <XYZ>:
	         No suitable driver found for jdbc:odbc:XYZ

19928: ODBC option removed from Builder and Historian GUI
	The checkbox labeled "Use ODBC Driver" has been removed from the SQL Add Database 
	dialog in the Builder and also from the Database Options panel of the Historian 
	UI. This change was made because the JdbcOdbc driver is no longer supported by 
	Oracle beginning in Java 1.8 and in earlier releases it was not intended for 
	production use. 
	
	If an existing OPTIONS.ini or HISTORY.ini file contains a database connection 
	that was saved with the "Use ODBC Driver" box checked, those connections will 
	still work in this release if run with java < 1.8. In the new UI, such entries 
	will now show: 
	
	    JDBC Driver Class Name : sun.jdbc.odbc.JdbcOdbcDriver
	    JDBC Database URL : jdbc:odbc:<dbname>
	
	... rather than showing the checked "Use ODBC Driver" box.
	
	But, if run with java 1.8 or newer, the following error will appear in the 
	console for each database that is configured to use ODBC: 
	
	ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver (ODBC driver is not 
	available in Java 1.8 or newer) 

20191: Prevent data with timestamp < historyTimeSpan from going to history
	In prior releases, a row with a timestamp older than a cache's historyTimeSpan 
	could be added to the cache's history table and would not be removed until the 
	next update. In this release this has been fixed so that such a row is not added 
	to the history table in the first place. 

Display Server

18024: Fixed ArrayIndexOutOfBounds on Grid containing more than 1 icon type
	In prior releases, the display server threw an ArrayIndexOutOfBounds exception if 
	a display was opened containing an object grid configured with more than one icon 
	per item, and the display was not rendered in the thin client. This is fixed. 

20237: Touchscreen PCs no longer display thin client in tablet mode
	In prior releases, if the thin client was opened in a browser on a PC with a 
	touchscreen, items would be missing from in the right-click context menu. The 
	missing items includied the Drill Down, Execute Command, and Export Table to 
	Excel items, plus any custom menu items. This is fixed. 

20582: Enable mouse cursor to change appearance when hovering over composites
	If a composite object has its drilldownTarget set, then in the thin client the 
	"hand" cursor will appear when the mouse is over the composite. This is 
	consistent with the behavior of other objects that have a drilldownTarget. 

20621: Fixed: obj_rect_il may not draw in comp grid if webLabelFlag=1
	A bug in the thin client has been fixed that sometimes caused objects with the 
	webLabelFlag property checked to not to be drawn if the objects were in a 
	composite display inside an object grid instance. 

20623: Table no longer fails to populate when cellsperpage is smaller than visible cells
	A bug in the display server has been fixed which sometimes caused table cells in 
	the thin client to always contain "..." if the cellsperpage property was set. 
	Typically this occurred if the cellsperpage value was small (in the range of 1000 
	to 2000) and a table with many columns was opened. It was unlikely to occur with 
	a typical cellsperpage value of 10000 or more. The problem is fixed for all 
	cellsperpage values. As before, a value less than 1000 is ignored. 

Object Library

20142: Fixed minor usability problems with tree/accordion control
	The following minor problems with the tree and accordion control object are 
	fixed: 
	
	1 The initialExpandDepth property is now only applied to new branches. 
	Previously, on a tree control with valueTableType = Row-node the 
	initialExpandDepth was improperly reapplied on each update to the tree, reopening 
	any existing branches that the user may have closed. 
	
	2. In the thin client, the labels on accordion buttons are now aligned properly: 
	Parent (non-leaf) node labels are left aligned, and leaf node labels are center 
	aligned. This is consistent with the accordion in the builder/viewer. Previously, 
	parent node labels were center aligned in the thin client, which was incorrect. 
	
	3. On a tree control In the thin client, a click on the +/- icon now opens/closes 
	the tree branch as expected but it no longer selects the node or triggers the 
	tree control's command. This is now consistent with the tree control behavior in 
	the viewer. 
	
	4. On an accordion control In the thin client in most browsers, a click on a 
	left/down arrow icon now opens/closes the branch as expected but it no longer 
	activates the accordion button or triggers the accordion control's command. 
	However, in IE version 8 or older, and in the viewer, the accordion button is 
	still activated and the control's command is executed. 

Reporting

20052: Tibco Spotfire reports added for Engine Metrics
	An example Tibco Spotfire dashboard is available to run for both MySQL and Oracle 
	SQL databases. The dashboard can report on historical data for BW Engine Metrics 
	and can be run using Tibco Spotfire Desktop version 7.0. 
	
	The dashboards and associated SQL custom query text files are located in the 
	rtvapm/bwmon/projects/reports/Spotfire directory. They include: 
	
	bw_engines_mysql.dxp (for MySQL)
	bw_engines_mysql.txt 
	bw_engines_sql.dsp (for Oracle SQL) 
	bw_engines_sql.txt 
	
	For more information, please refer to the User Guide.

Scripts

19952: Solaris 10 Script change not always executed
	On Solaris 10 systems the rtvapm_init.sh script modifies other scripts in 
	common/bin to use the bash shell. Under certain conditions this operation was not 
	executed. This has been fixed. 

Servers

20020: Prevent Hawkmon from filtering out blank Processor fields
	Under some conditions Hawkmon would fail to correctly identify Hawk agents, which 
	could then affect other parts of the product such as Servers in BWmon. This 
	occurred if the Hawk data contained a blank value for the getCpuInfo Processor 
	field . This has been corrected. 

Solution Package

TIBCO Hawk

20581: Adjusted margins for tables in Hawk displays
	Cosmetics (margins around tables and fields) have been adjusted for the Hawk 
	Agent Table and Hawk Alert Table for the sake of consistency with other displays. 
	No functional changes were made to these displays. 

20624: Added buffer to HawkAgents cache to prevent missed updates
	In previous versions where multiple sender dataservers forwarded copies of their 
	HawkAgents cache to a single receiving dataserver (ie, remote collectors with a 
	central aggregator), it was possible that the receiver could drop updates. This 
	has been corrected by adding row buffering to the receiver. 

20646: Expiration removed from the HawkAgent cache
	Rows in the HawkAgents cache only update when asynchronous events like hawk 
	alerts or onAgentAlive/onAgentExpired are received, so it is normal for rows to 
	not update for lengthy periods. Hence, the Expired column has been removed from 
	the HawkAgents cache and associated tabular display. 

Version 6.2.0 Release Notes

BW Monitor Microagent

19802: BW versions no longer read incorrectly on certain BW servers
	In certain cases the BW Monitor Servers data would include the incorrect BW 
	Version, i.e., when there are additional BusinessWorks plugins installed in the 
	BW server. This has been fixed. 

Configuration

19462: Update in the TRA  microagent set to 300 seconds
	The RTView plugin microagent for BW Monitor has an update setting which will 
	cause it to re-read the Tibco deployment files on the specified period. This 
	enables it to find engines that have been newly deployed or undeployed. 
	
	The default update setting is now 300 seconds (5 minutes) and may be changed by 
	editing the line "<arg>-update:300</arg>" in 
	$TIBCO_HOME/tra/domain/<name>/plugin/BWAgentPlugin.hma. 

Data Historian

19368: 'Active' column in bw_process cache reverted back to type long
	In EM 1.4.2 the data type for the ‘Active’ field in the bw_process cache changed 
	from a type of long to integer. This may have caused problems reading from 
	database tables defined with a column type of BIGINT for ‘Active’. This change 
	has been reverted so that ‘Active’ is again a type of long. 

Deployment

19816: Corrected failure to obtain server data on Solaris
	Previously BW Monitor could not obtain BW Server data from a BW Server/hawk Agent 
	running on Solaris. This has been corrected. 

Engines

19215: All Engines table Clear button fixed
	The BW Monitor All BW Engines Table has a text field for filtering on the Engine 
	Name and an associated Clear button to clear the text field and return to the 
	full display. In the thin client this button did not correctly clear the text 
	field. This has been fixed. 
	
	Also a checkbox labeled "Regex" has been added. This will select whether the 
	string entered in the text box is interpreted as a simple wildcard expression or 
	a full Regular Expression. 

19296: Enhance discovery of BWSE engines
	The BW Monitor can be configured to discover BW Engines running as BWSE 
	components of an AMX service implementation. The engines must be configured with 
	HawkEnabled=true. 
	
	To enable the discovery of BWSE engines you may edit rtview.properties and 
	uncomment two lines, or copy those lines to your own properties file. The lines 
	are: 
	
	collector.sl.rtview.hawk.enablematable true
	collector.sl.rtview.cache.config=bw_engine_microagents.rtv

19306: Provide process data subset; add all engines all processes display
	BW Monitor has been enhanced with an alternative All BW Processes table, which 
	can be enabled to replace the default table (or be used in addition to it) by 
	editing the bwmon_navtree.xml file. This table has the option to display all BW 
	Processes across all BW Engines and BW Servers but with a subset of table 
	columns. The column subset used in the table is specified by the 
	$bwprocessColumnSubset property in rtview.properties, e.g. 
	
	sl.rtview.sub=$bwprocessColumnSubset:'Active;Created;Completed;AverageExecution;'

19313: Add Active Processes to engine table and heatmap.
	The BW Monitor All Engines table and heatmap have been enhanced with the addition 
	of the metric Active Processes. This per-engine value is distinct from Running 
	Processes in that it is calculated by BW Monitor each update using data returned 
	by the Hawk GetProcesses method. 

19566: CPU% utilization no longer rounded to zero if ess than 1
	BWMON 6.1 was modified to use EM's hawkmon solution package to collect host and 
	process metrics. In the case of process CPU utilization (as displayed in BWMON's 
	all engines table), hawkmon used the integer CPU utilization directly from hawk, 
	whereas earlier versions of BWMON calculated %CPU from the CPU Time metric.The 
	result is that BWMON 6.1 displayed zero % CPU when the actual percentage was less 
	than 0.5, whereas older BWMON versions displayed a fraction. Hawkmon has been 
	updated to calculate % CPU the same way previous versions of bwmon did, so the 
	older behavior is now present in newer releases of bwmon. 

General

19621: Sorting consistency improved on BW Table displays
	The BWmon Server and Process tables are now sorted initially by the item they 
	display, like the Engines table. The order of Activities in the table is left as 
	it comes from the source. 

19851: Flashing "expired" status fixed
	Under some conditions in a multi-dataserver environment, a BW Server that was 
	expired would cycle between expired and unexpired in the displays. This has been 
	corrected. 

Processes

19324: Reduce amount of process data sent by the sender data server
	BW Monitor has been enhanced with the ability to limit the amount of BW Process 
	data sent by the BW Monitor data server in sender mode. The user may specify a 
	subset of the available Process table columns to be sent via a new property in 
	rtview.properties, e.g. 
	
	sl.rtview.sub=$bwprocessColumnSubset:'Active;Created;Completed;AverageExecution;'
	
	In addition an alternative sender file must be selected as per the instructions 
	in rtview;properties: 
	
	#
	# Sender functions
	#
	sender.sl.rtview.cache.config=bw_rtvagent_sender.rtv
	#
	# Sender functions for process table subset
	# (Comment out the line above and uncomment the one below)
	#
	#sender.sl.rtview.cache.config=bw_rtvagent_sender_subset.rtv

19809: BW Process history table now disabled by default
	By default BW Monitor will no longer save historical BW Process data to the 
	database. To enable the collection of historical BW Process data find the 
	following section in rtvapm.bwmon.properties and proceed as indicated. 
	
	##########################
	# HISTORIAN PROPERTIES
	
	#
	# By default we disable collection of historical data for Processes.
	#
	sl.rtview.sub=$BW_PROCESSES_TABLE:''
	sl.rtview.sub=$BW_ACTIVITY_TOTALS_TABLE:''
	#
	# To enable this, copy the following two lines into your local properties and 
	uncomment them: 
	#
	#sl.rtview.sub=$BW_PROCESSES_TABLE:BW_PROCESSES
	#sl.rtview.sub=$BW_ACTIVITY_TOTALS_TABLE:BW_ACTIVITY_TOTALS

RTView Core Functionality

Builder - Editing

19879: Fixed NPE when deleting local var with same name as global
	A bug has been fixed in the Builder which caused a NullPointerException to be 
	thrown if a local variable was deleted and the local variable had the same name 
	as a global variable. 
	

Data Historian

19469: Avoid removal of all batch data when some data is wrong.
	The historian will no longer discard all rows in a batch if a SQL exception is 
	thrown during an row insert. Instead it will catch the exception and continue 
	with the other row inserts in the batch and commit all of the successful inserts 
	at the end of the batch. 
	

19786: smoothCompaction no longer throws NPE when there are no compaction rules
	Previously a NPE was thrown when -smoothcompaction was used with a cache with a 
	compaction type of "aggregate" but with no compaction rules. 
	
	Now this scenario fails silently.
	
	
	

19915: Simple retention now applied only to tables without compaction rules
	If a cache history table that was persisted by the historian had no compaction 
	rules, then the simple retention time limit was applied to ALL tables persisted 
	by the historian. This was incorrect. The simple retention limit will now only be 
	applied to tables without compaction rules. 
	

Data Sources

19977: New onData Length column 
	The TIBCO Hawk data source has been enhanced to include a new onData Length 
	column in the RTViewDs GetSubscriptionStatus method. This column contains the 
	amount of time, in milliseconds, that the last onData call took to process the 
	subscription data. 
	

Display Server

19880: Fixed unstable dropdown list in FF & Chrome
	In prior versions of the thin client, on each display refresh the dropdown list 
	of the combo box control would scroll and the highlighted list item would change, 
	even if the refresh did not change the items in the list. This behavior could 
	make it difficult to use the dropdown list. This problem has been fixed. 
	
	Note that this problem affected the thin client in Firefox and Chrome, but not 
	Internet Explorer. 
	

General

19933: rtvquery default time range for current table changed from 30s to ALL
	The rtvquery servlet will no longer apply a default time range of 30 seconds to 
	queries on the current table of a cache. Instead, it will apply a default time 
	range of zero, which will return all rows from the current table regardless of 
	their timestamp. 
	
	A default of 30 seconds will still be applied to all queries on cache history 
	tables. 
	
	Note that the time range, in seconds, can be specified with the tr parameter in 
	the URL. For example, this query will return the last 10 minutes of history data 
	from a cache named Servers: 
	
	  http://host:port/rtvquery/cache/Servers/history?tr=600
	
	

Object Library

19861: Support HTML label object in the thin client
	A number of simple RTView graphical objects have been enhanced to allow them to 
	be rendered as HTML elements in a thin client deployment, rather than rendered in 
	the image generated by the Display Server. This enhancement can improve system 
	performance in some cases and also allows the user to copy text strings in the 
	objects to the clipboard. Most of the objects affected by this enhancement are 
	found on the General tab and Labels tab in the Builder's object palette. The 
	enhanced objects are: 
	
	    obj_rect
	    obj_rect_il
	    obj_rect_ilv
	    obj_rect_ilvs
	    obj_rect_ilvx_da3
	    obj_rect_ilvx_ra4
	    obj_circ2d
	    obj_circ2d_il
	    obj_circ2d_ilv
	    obj_circ2d_ilvs
	    obj_circ2d_ilvx_da3
	    obj_circ2d_ilvx_ra4
	    obj_label05
	    obj_label05s
	    obj_label11
	    obj_label11s
	    obj_text01
	    obj_c1btn_chk
	
	These objects now support a new a new property named webLabelFlag. In a display 
	server deployment, if webLabelFlag is true (checked) then the object will be 
	rendered as HTML in the thin client, rather than rendered in the image by the 
	display server. This allows the display server to update the individual object, 
	if necessary, when the display is refreshed, rather than regenerating the entire 
	display image. 
	
	If all of the dynamic objects on a display can be rendered as HTML, this can 
	improve the performance of the display server and thin client. The list of 
	objects that can be rendered as HTML now includes all the objects listed above, 
	all objects on the Controls tab in the object palette (obj_c1*), the table object 
	(obj_table02), and the trend chart (obj_fxtrend). Another advantage of setting 
	webLabelFlag on an object is that it allows the user to select the object's text 
	and copy it to the clipboard. 
	
	By default webLabelFlag is false (unchecked). The webLabelFlag property is listed 
	in the "Label" category in the Builder's property sheet. The webLabelFlag can be 
	set on all of the objects listed above via the following entry in an rtview 
	stylesheet (.rts) file: 
	
	rtv-all {
	   webLabelFlag: 1;
	}
	
	In certain cases, an object included in the list above will still be rendered in 
	the image by the display server even if webLabelFlag = true. These cases are: 
	
	 - the display is opened in Internet Explorer 8 or older.
	 - the display server is run with the -nohtml5 option on the command-line. 
	 - an obj_text01 instance with rotated text (a nonzero value for rotationAngle).
	 - an obj_rect* with labelTextPosY = Tab Top
	 - an obj_rect* with labelTextPosY= Title Top and bgBorderFlag = true
	 - an obj_label* with bgStyle = Round Rectangle
	- the object is inside an object grid, and is not inside a composite object in 
	that grid 
	- the object is an obj_rect* and there is a non-html object above it in Z-order 
	which overlaps (for example, an obj_rect instance used as a background behind 
	several meter objects) 
	 
	In other cases, an object may have a slightly different appearance in the thin 
	client when it is rendered as HTML, as follows: 
	
	- only vertical and horizontal gradients are supported on HTML objects in the 
	thin client, so if an object has its bgGradientMode property set to "Diagonal 
	Edge" or "Diagonal Center" it is treated as "Vertical Edge" instead. 
	 
	 - the object's bgShadowFlag property is ignored
	 
	Note that the webLabelFlag property has no effect in the builder or viewer (thick 
	client). 
	
	

19934: New property to limit size of label area
	The status history object (obj_statushistory) supports a new property named 
	barLabelMaxLengthPct. This can be used to specify the maximum length for each bar 
	label as a percentage of the plot area width. The default is zero which means no 
	limit is applied to the label length. 
	
	If a positive value is specified for both the barLabelMaxLength and 
	barLabelMaxLengthPct properties, then the smaller length limit of the two will be 
	used. 
	

19935: Newlines now supported in mouseover
	The status history chart (obj_statushistory) will now properly convert a 
	backslash-n sequence into a newline when displaying the mouseover (tooltip) 
	string. This string is acquired from the column specified by the chart's 
	descriptionColumnName property. 
	

19938: HTML5 obj_trendgraph02 no longer ignores data table with 1 column
	A problem in the display server has been fixed which prevented an 
	obj_trendgraph02 instance with webChartFlag = 1 from plotting any data points on 
	trace N if traceNValue was attached to a table containing a single numeric 
	column. 
	

Reporting

19939: obj_trendgraph02 using HTML 5 can now be exported to PDF
	A problem has been fixed which prevented an obj_trendgraph02 instance with 
	webChartFlag = 1 from being included in the output of the thin client's "Export 
	to PDF" option. 
	

Servers

19850: Default server expiration time raised to 300 seconds
	The default value for $bwserverExpirationTime has been raised to 300 (seconds), 
	so as to be less sensitive to network delays, variance in system clocks, etc. 
	
	To change this value copy the following line into your local properties and edit 
	it: 
	
	sl.rtview.sub=$bwserverExpirationTime:300

Version 6.1.0 Release Notes

Alerts

18406: Integrate new EM alert notifier
	Alert notifications in BW Monitor have been enhanced to support easier 
	integration with EM. In order to support this, the previously supported 
	notifications properties are no longer being used. See the upgrade notes section 
	below if you have modified or overridden the values for any of the notification 
	properties. 
	
	The following properties are defined in rtvapm.properties for notifications:
	
	sl.rtview.alert.notifierenabled - Set to true to enable alert notifications. This 
	defaults to true. To disable alert notifications, set this to false. 
	
	sl.rtview.alert.notifiercommandnew - Set this to the command to execute when a 
	new alert is generated. This defaults to executing the my_alert_actions.bat. To 
	execute my_alert_actions.sh, set the following: 
	
	sl.rtview.cmd_line=-sub:$scriptEnding:sh. 
	
	To execute a different script with the same arguments, set the following (where 
	my_script is the name of your script): 
	sl.rtview.cmd_line=-sub:$alertActionScript:my_script
	
	sl.rtview.alert.notifiercommandsevincrease - Set this to the command to execute 
	the first time an alert changes severity. The default for this is the same as the 
	sl.rtview.alert.notifiercommandnew. 
	
	sl.rtview.alert.notifiercommandcleared - Set this to the command to execute the 
	when an alert is cleared. By default, no command is configured. To execute a 
	script, copy the notifiercommandnew line and replace $alertActionScript with the 
	name of the script you want to execute. To execute a custom java command, see the 
	example in common\conf\custom_handlers.properties. 
	
	sl.rtview.alert.notifiercommandchanged - Set this to the command to execute when 
	a column in the alert table changes. To execute a script, copy the 
	notifiercommandnew line and replace $alertActionScript with the name of the 
	script you want to execute. To execute a custom java command, see the example in 
	common\conf\custom_handlers.properties. This must be used in conjunction with the 
	sl.rtview.alert.notifiercolumns property 
	
	sl.rtview.notifiercolumns - Set this to the name of one or more columns to 
	execute the sl.rtview.alert.notifiercommandchanged notification when they change. 
	For multiple columns, use a semi-colon delimited list. Note that this should be 
	limited to the minimum number of necessary columns, preferably less than 5, as a 
	large number of columns increases the persistence load on the central alert 
	server. 
	
	You may alternatively execute a custom java command instead of a script for alert 
	notifications. An example of this is provided under 
	RTVAPM_HOME\bwmon\sample\custom. To use the sample custom code, you must build it 
	and add the custom package and jar to your application: 
	
	1. Run RTVAPM_HOME\bwmon\sample\custom\make_classes.bat. This will build the 
	custom handlers and output them in 
	RTVAPM_HOME\bwmon\sample\custom\lib\rtvapm_custom.jar. 
	2. Modify common\conf\custom_handlers.properties to uncomment the 
	sl.rtview.alert. notifiercommandnew line. Also, modify the sl.rtview.cp line to 
	%RTVAPM_HOME%/bwmon/sample/custom/lib/rtvapm_custom.jar. You can optionally 
	uncomment the sl.rtview.alert.notifiercommandsevincrease, 
	sl.rtview.alert.notifiercommandcleared, sl.rtview.alert.notifiercommandchanged 
	and sl.rtview.alert.notifiercolumns lines if you want those additional 
	notifications to execute your custom java command notification. 
	3. When you run the data server, add the following to the command line: 
	-properties:%RTVAPM_HOME%/common/conf/custom_handlers 
	
	Upgrade Information
	The following properties from rtvapm\common\conf\rtvapm.properties have been 
	removed or replaced. If you have modified any of these properties in 
	rtvapm\common\conf\rtvapm.properties or overridden them in your properties file, 
	you will need to make the following modifications. 
	
	sl.rtview.alert.alertcommand - use sl.rtview.notifiercommandnew instead. Also set 
	the same value on the sl.rtview.notifiercommandfirstsevchange property if you 
	want to receive a notification the first time the severity changes on an alert. 
	If you do not want to receive notifications the first time the severity changes 
	on an alert, set sl.rtview.notifiercommandfirstsevchange to a blank value. 
	
	sl.rtview.alert.renotificationmode - This property is no longer supported.
	
	sl.rtview.alert.renotifyonsevchangedmode - This property is no longer supported. 
	This property previously defaulted to 1. If you set it to 0, set the 
	sl.rtview.notifiercommandfirstsevchange to a blank value. If you set it to 1, set 
	the sl.rtview.alert.notifiercommandchanged to the same value as 
	sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property 
	to Severity. With this configuration, you will get a notification each time the 
	Severity changes. If you only want to act on increases, add logic to support this 
	to your script or custom command code. 
	
	sl.rtview.alert.renotficationcommand - This property is no longer supported.
	
	sl.rtview.alert.commentcommand - This property is no longer supported. To receive 
	notifications when the comment changes, set the 
	sl.rtview.alert.notifiercommandchanged to the value you previously used for the 
	commentcommand property. Set the sl.rtview.alert.notifiercolumns property to 
	Comments. 
	
	sl.rtview.alert.alertclearedcommand - This property is no longer supported. Use 
	the sl.rtview.alert.notifiercommandcleared property instead. 

19169: BWM will show duplicates of Hawk alerts
	BW Monitor Solution Package (1.4.0) was showing duplicate entries for in the 
	alerts table for Hawk alerts. This has been corrected. 

BW Monitor Microagent

19073: Periodic update now disabled by default
	In the BWAgentPlugin.hma file the argument -update is now commented out. This 
	allows it to take its default value of 0, which disables the periodic update of 
	the deployment data by the BWAgentPlugin microagent. If the argument is 
	uncommented and given a nonzero value (seconds) the microagent wil update its 
	deployment data on that interval. 

Engines

18717: Engines that are deployed but not active are now shown
	If a BW server had engines deployed but none were active, BW Monitor would show 
	no engines at all for that server. This has been corrected. 

Platform Support

17315: Support for BWSE (ActiveMatrix)
	BW Monitor can now display BW Engines running as BWSE components in an 
	ActiveMatrix environment. See the documentation for instructions on configuring 
	BW Monitor appropriately. 
	
	Limitations:
	
	(1) JVM memory metrics will be available for BWSE components running in AMX 3.x 
	environments only. 
	
	(2) The BW Version column in the Engines table will be blank for BWSE components.
	
	(3) The Deployment column in the Engines table will be UNKNOWN for BWSE 
	components. The AMX environment controls in which node or nodes a BWSE component 
	is running so the concept of "deployment" in traditional BusinessWorks does not 
	apply. 
	
	(4) Likewise, BWSE components will only appear in the Engines table when they are 
	running in a node. 
	

Servers

18622: Fixed incorrect engine data with two domains on same server
	Previously BW Monitor would return an incorrect list of deployments if a user was 
	querying multiple domains on the same server. The list returned would show each 
	domain as having the deployments of both domains. This problem did not occur if 
	the user queried each domain separately. 
	
	This has been fixed, so that now the list returned will show the correct 
	deployments for each domain. 

18821: Deployed Engines and Active Engines added to All Servers pages
	The columns Deployed Engines and Active Engines have been added to the All 
	Servers Table and Heatmap displays. In the Heatmap these metrics may be selected 
	in the dropdown list and seen in the mouseover tooltip. 

19120: Server process summary pages disabled by default
	The BW Monitor Server Processes and Server Process Summary pages are not enabled 
	by default, because (due to limitations in Tibco Hawk) the data they display is 
	not available from IBM AIX or HP-UX servers. 
	
	To enable these displays, edit bwmon_navtree.xml in the project directory and 
	uncomment the following two lines, then restart BW Monitor. 
	
	<!-- <node label="Server Processes" display="bw_server_processes"/> --> 
	<!-- <node label="Server Process Summary" display="bw_server_process_summary"/> 
	--> 

Version 6.0.0 Release Notes

Activities

18312: Agent deployments have been optimized
	In a sender-receiver dataserver deployment, the communication between sender and 
	receiver has been improved to be more efficient. 

Alerts

18177: Support global alert notification definitions
	Alert notification is now user-configurable via properties. The defaults are:
	
	- The alert command is my_alert_script.bat.
	- The alert command executes for new alerts and on the first severity change.
	
	To configure notification, you no longer need to modify the .rtv files, just set 
	properties and customize the alert handler script to your needs. 
	
	- (Windows) To use my_alert_actions.bat, copy it from common\bin to your project 
	directory and modify the end of the script to do the appropriate action. 
	- (Linux) To use my_alert_actions.sh, copy it from common\bin to your project 
	directory and modify the end of the script to do the appropriate action. Add your 
	project directory to the start of your path environment variable, or add "./" to 
	your $alertActionScript in conf/rtvapm_oramon.properties as follows. 
	sl.rtview.cmd_line=-sub:$alertActionScript:./my_alert_actions
	 Also, add this to your properties file:
	sl.rtview.cmd_line=-sub:$scriptEnding:sh
	- To use a different script, add it your project directory and add the following 
	to your properties file: 
	sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where 
	"my_custom_script" is the name of your script. If it does not use the .bat 
	extension, also add the following to your properties file: 
	sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your 
	script. 
	- To use a different command, add the following property to your properties file: 
	sl.rtview.alertCommand=XX where XX is the command to execute. This can be any 
	RTView command string. See the documentation for the alertCommand property on any 
	of the alerts for more information on this. 
	
	There are also several properties that the user can now set that were not 
	previously documented. You can get more info on these from the alert 
	documentation on the Global Notifications app option tab. At the time this rn was 
	written, the global notifications hadn't been added to the docs yet, but the 
	concepts can be found in Alerts->Alert Types->Limits in the descriptions for 
	these properties: reNotificationMode, reNotificationTime, 
	reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, 
	commentAddedCommand. 
	
	sl.rtview.alert.renotificationmode
	sl.rtview.alert.renotificationtime
	sl.rtview.alert.renotifyonsevchangedmode
	sl.rtview.alert.renotficationcommand
	sl.rtview.alert.commentcommand
	sl.rtview.alert.alertclearedcommand
	

18253: Custom handler and custom alert command added to sample project
	BW Monitor has been enhanced with an optional custom package that lets you define 
	custom functions and commands. The custom package code is in 
	%RTVAPM_HOME%\bwmon\projects\sample\custom\src\com\sl\rtvapm\custom. To build the 
	custom package classes, run 
	%RTVAPM_HOME%\bwmon\projects\sample\custom\src\make_classes.bat. This will build 
	the classes and output them in 
	%RTVAPM_HOME%\bwmon\projects\sample\custom\lib\rtvapm_custom.jar. 
	
	You may modify the custom function handler, RtvApmFunctionHandler.java, to 
	implement custom functions for use in custom displays. The custom function 
	handler api is described in the RTView Classic documentation under 
	Customization->Custom Functions and Customization->Customization API. 
	
	You may modify the custom command handler, RtvApmCommandHandler.java, to 
	implement custom commands for use in custom displays or as alert notification 
	commands. The custom command handler api is described in the RTView Classic 
	documentation under Customization->Custom Commands and 
	Customization->Customization API. 
	
	To enable these classes, include 
	%RTVAPM_HOME%\common\conf\custom_handlers.properties in your command line: 
	
	-properties:%RTVAPM_HOME%/common/conf/custom_handlers
	
	The RtvApmCommandHandler class contains a sample alert notification command named 
	my_alert_command. You can use this example as a starting place to implement your 
	own custom alert notification command. To use the my_alert_command custom command 
	for alert notifications, uncomment the sl.rtview.alert.alertcommand line in 
	%RTVAPM_HOME%\common\conf\custom_handlers.properties. 
	

BW Monitor Microagent

17986: Microagent discovery now catches deployments with added fields
	The RTView microagent expects domains listed in the file 
	<tibco-home>/tra/domain/DomaonHomes.properties to contain information of the 
	format: <domain-name>.TIBCO_TRA_DOMAIN_HOME=<tibco-home>/tra/domain 
	
	In some deployment configurations, additional information may be in these lines 
	between the domain name and TIBCO_TRA_DOMAIN_HOME. This will cause the microagent 
	to fail in the discovery of deployment information and will cause all engines 
	that are running to be indicated as status LIMITED and those that are not running 
	will not appear at all. 
	
	The BWM RTVIew microagent has been enhanced to properly discover deployment 
	information with these types of deployments. 

17991: Corrected Max Heap overflow when > 2GB
	On 64-bit systems the BW Microagent could return incorrect values for BW engine 
	Max Heap Size. These values would cause other memory metrics to be incorrect. 
	This has been corrected. 

Configuration

18130: Create scripts to manage multiple configurations of servers
	RTView has been enhanced with the addition of commands to start, stop, and get 
	the status of multiple processes (servers and clients) that are managed together. 
	
	For any type of deployment there is a set of RTView processes to manage; we will 
	refer to this set of processes as a ?configuration?. Configurations are specified 
	in a simple text file in your project settings directory named rtvservers.dat. 
	(See note about project settings directories below.) 
	
	Here is an example file:
	
	default		.	dataserver		rundata
	default		.	historian		runhist -ds
	default		.	displayserver		rundisp -ds
	default		.	database		rundb
	
	Each line has four fields:
	
	? The configuration name (?default? in this case). This may be any name you 
	choose. 
	? The location of the project settings directory, relative to the location of the 
	rtvservers.dat file (?.?, or current directory, in this case) 
	? The property filter which identifies the server (specifically, the property 
	filter under which the server?s JMX port is defined). By default this is the 
	server name: dataserver, displayserver, historian, etc. 
	? The command line used to start the process. Typically you will use one of the 
	following commands: 
	
	Command		Process started
	rundata		Data Server
	runhist		Historian
	rundisp		Display Server
	rundb		Database (HSQLDB)
	runv		Viewer
	
	The command line may include additional arguments such as -properties and 
	?propfilter. 
	
	*NOTE: the commands listed above may also be used directly in a command prompt or 
	shell window. On Windows you may type the commands as shown; on Unix systems you 
	must add .sh to each command, e.g. rundata.sh, runv.sh, etc. 
	
	*NOTE: you may write the paths using forward-slash notation on both Windows and 
	Unix systems. For example if your project settings directory were located in a 
	sub-directory below the location of your rtvservers.dat file, you would write the 
	path as ./subdirectory on both Windows and Unix. 
	
	The above example is for a web application deployment. In the case of a desktop 
	deployment you would not start the Display Server, and you would start the Viewer 
	desktop application; in this case the rtvservers.dat file could look like this: 
	default		.	dataserver		rundata
	default		.	historian		runhist -ds
	default		.	viewer			runv -ds
	default		.	database		rundb
	
	Here are the three commands that, together with the rtvservers.dat file, enable 
	you to manage your configurations: 
	
	Command		Description
	start_rtv	Starts servers and clients using the run command line
	stop_rtv	Stops servers and clients using their defined JMX ports
	status_rtv	Displays status of servers and clients using their defined JMX ports
	
	*NOTE: On Windows you may type the commands as shown; on Unix systems you must 
	add .sh to each command, e.g. start_rtv.sh, stop_rtv.sh, etc. 
	
	Each command used without arguments will give a usage message and list the 
	available configurations: 
	> start_rtv
	
	Usage: start_rtv config [server]  or 'all'
	Available configs:
	    default
	
	As indicated, each command may take:
	? the name of a configuration, in which case the action will apply to all the 
	servers or clients specified in the configuration 
	? the keyword all, in which case the action will apply to all configurations in 
	the file 
	? the name of a configuration followed by the name of a server, in which case the 
	action will apply only to that server (or client) as specified in the 
	configuration 
	
	In addition the start_rtv command may take:
	? an optional argument ?console (or ?c). Normally the processes are started 
	without a command window (on Windows) or standard output to the console (Unix); 
	this argument changes this behavior and is useful for testing. 
	?	Other optional arguments to be included in the run command line.
	
	*NOTE: On Windows the HSQLDB server (if used) will always run with a command 
	window and cannot be stopped via the stop_rtv command. You may stop it by typing 
	ctrl-C in its command window. 
	
	Here are some examples using the default configuration.
	
	*NOTE: since there is only one configuration in the default file, the following 
	commands could specify all as well as default for the configuration. 
	
	> start_rtv default
	
	Start default:
	dataserver:  Executing rundata -bg
	displayserver:  Executing rundisp -ds -bg
	historian:  Executing runhist -ds -bg
	database:  Executing start/min rundb
	
	> status_rtv default
	
	Status default:
	dataserver: Running PID 4696 Uptime 000:00:01:47 CPU 00:00:02 Heap 0.7% Clients 2 
	displayserver: Running PID 6340 Uptime 000:00:01:45 CPU 00:00:01 Heap 1.0% 
	Displays 0 
	historian: Running PID 6108 Uptime 000:00:01:42 CPU 00:00:01 Heap 1.3% Connected 
	true 
	database:  Running  PID 6848  Uptime 000:00:01:39  CPU 00:00:00  Heap 0.4%
	
	Note the Data Server reports two clients: those are the Display Server and 
	Historian, both of which were started with the ?ds argument, telling them to 
	connect to the Data Server. Note also the Historian reports it is connected to 
	the database 
	> stop_rtv default dataserver
	
	Stop default:
	dataserver:  Stopped PID 4696 via JMX port 3368
	
	> status_rtv default
	
	Status default:
	dataserver: Running PID 6256 Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 
	displayserver: Running PID 2216 Uptime 000:00:02:48 CPU 00:00:00 Heap 1.1% 
	Displays 0 
	historian:  Stopped
	database:  Running  PID 6848  Uptime 000:00:10:57  CPU 00:00:00  Heap 0.6%
	
	Note that with the Historian stopped, the Data Server has only one client.
	
	> start_rtv default
	
	Start default:
	historian:  Executing runhist -ds -bg
	
	Note the start_rtv command only tries to start processes it determines to be 
	stopped. 
	
	The status_rtv command will report if a configured port is in use but the process 
	using it does not appear to belong to RTView: 
	
	dataserver:  Data port xxx in use by PID yyy
	displayserver:  JMX port xxx in use by PID yyy
	
	If no JMX port is configured the  stop_rtv  command will just report :
	
	dataserver:  No JMX port configured; must kill PID xxx by system command.
	
	If the port is in use but the PID is not available (HP-UX, some Linux systems) 
	then the stop_rtv and status_rtv command will report the PID as ?????, for 
	example: 
	
	dataserver: Running PID ??? Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 
	dataserver:  Stopped PID ??? via JMX port 3368
	
	Finally, please note the following. If multiple configurations are specified in 
	the rtvservers.dat file with different locations for the project settings 
	directory, the all argument will cause them all to be processed. However if they 
	are specified with the same startup directory they are considered alternative 
	configurations and only the first one will be processed. 
	
	For example you might have two installed RTView monitors and want to start them 
	both: 
	
	bwmon	./bwmon		dataserver		rundata
	bwmon	./bwmon		historian		runhist -ds
	bwmon	./bwmon		displayserver		rundisp -ds
	
	bwmon2	./bwmon2	dataserver		rundata
	bwmon2	./bwmon2	historian		runhist -ds
	bwmon2	./bwmon2	displayserver		rundisp ?ds
	
	In this case the all  argument would cause both configurations to be processed.
	
	On the other hand you might want to have alternative configurations for one 
	RTView monitor, such as desktop deployment and browser deployment: 
	 
	desktop		./bwmon	dataserver		rundata
	desktop		./bwmon	historian		runhist -ds
	desktop		./bwmon	viewer			runv -ds
	
	browser		./bwmon	dataserver		rundata
	browser		./bwmon	historian		runhist -ds
	browser		./bwmon	displayserver		rundisp -ds
	
	
	In this case the all argument would cause only the first configuration to be 
	processed. The second configuration could be processed by referring to it 
	explicitly, e.g. start_rtv browser. 
	

18319: Correct bad JOIN in BwServerNames cache, causing missing data
	In cases where a Hawk agent has a deficient or missing Process microagent, bw 
	monitor would fail to show any of the engines running on it, although it would 
	show the processes and activities of those engines. This has been corrected; now 
	if the Process:getProcess method does not return a matching PID for a given 
	engine, it will display normally except its CPU % will display as "Not 
	Available". 

18320: Disabled RTVHISTORY and ALERTDEFS dbs for sender data servers
	By default a dataserver will try to make connections for history and alert 
	definitions to a local hsqldb database. In a sender-receiver deployment the 
	receiver may need these connections but the sender does not, so they are now 
	disabled by default in rtview.properties for propfilter "sender". 

Data Historian

18153: Trend charts in BWMON now configured for history
	BWMon trend graphs now show historical data properly.

Deployment

18073: Remove HAWKOPTIONS.ini from distribution
	The file HAWKOPTIONS.ini is obsolete and may be removed.
	

18473: Solaris Sparc support
	The EM scripts use to start, stop, and run processes, would fail on Solaris 11 
	systems. This has been corrected. 
	
	On Solaris 10 systems the scripts are not compatible with "sh" (which is a strict 
	Bourne shell). As a workaround you can edit the scripts to specify a different 
	shell. The shell "bash" is recommended, but if it is not available "ksh" may be 
	used instead. 
	
	Edit the following files in $RTVAPM_HOME/common/bin and change the first line 
	from "#!/bin/sh" to "#!/bin/bash": 
	
	rtvapm_common.sh
	rtvapm_ports.sh
	start_rtv.sh
	status_rtv.sh
	stop_rtv.sh
	unix_run_apm_builder.sh
	unix_run_apm_database.sh
	unix_run_apm_dataserver.sh
	unix_run_apm_displayserver.sh
	unix_run_apm_historian.sh
	unix_run_apm_viewer.sh
	
	

Engines

17735: Show Business Works Version in Engine Display
	The All BW Servers table and All BW Engines table have been enhanced with the 
	addition of a column showing the version of TIBCO BusinessWorks in use on each BW 
	server. 
	

18460: UPTIME value mismatch in displays
	The values for BW Engine Uptime displayed in the All Engines table were 
	incorrectly formatted, and were inconsistent with the (correct) values on the 
	Engine Summary page. This has been fixed. 

Servers

18327: Server Free Memory MB no longer reported as 0 for linux servers
	The BW Monitor metric Server Free Memory MB would be reported as 0 if the Hawk 
	Agent was running on UNIX. This has been corrected. 

Version 5.9.0 Release Notes

Alerts

17317: Alert definition and alert event handling.
	Alert actions may be customized by editing the alert action script for the 
	appropriate platform, by default my_alert_actions.(bat, sh) in the startup 
	directory. 
	
	

Configuration

17512: New Property files mechanism
	Properties in rtview.properties specific to BWMonitor.  
	
	#############################
	# HAWK DATA SOURCE PROPERTIES
	#
	# Configure Hawk poll intervals here
	#
	sl.rtview.sub=$bwserverPollInterval:30
	sl.rtview.sub=$bwenginePollInterval:30
	sl.rtview.sub=$bwprocessPollInterval:30
	sl.rtview.sub=$bwactivityPollInterval:30
	#
	# Hawk agents and agent groups may be configured by running the 
	# Configuration Utility and modifying HAWKOPTIONS.ini, or here: 
	#
	#sl.rtview.hawk.hawkconsole unixagent rvd domaintest 7474 ; tcp:7474
	#sl.rtview.hawk.hawkconsole winagent rvd domaintest 7474 ; tcp:7474
	#sl.rtview.hawk.agentGroup WIN_AGENTS winagent(winagent)
	#sl.rtview.hawk.agentGroup UNIX_AGENTS unixagent(unixagent)
	

Data Historian

17511: History now provided for all BW metrics
	Each display which contains trend graphs has been enhanced so that users can set 
	the time range to view any historical information that has been captured by the 
	historian and stored in the historian database. 

Deployment

17069: Provide DB schemas for historian and alert properties
	The example SQL scripts for BW Monitor (rtvapm\bwmon\dbconfig) have been updated.

17356: Components now available as  Windows Services
	The RTVAPM data server, display server, and historian may now be installed and 
	uninstall run as Windows Services. 
	
	To install and run a server as a service you will use properties to supply the 
	service name and startup directory and then use the appropriate command to run 
	the server with those properties. 
	
	For example, to run a data server using "local.properties" as a service named 
	"BWMONdataserver", put this in local.properties: 
	
	installdata.sl.rtview.cmd_line=-install_service
	installdata.sl.rtview.cmd_line=-service:BWMONdataserver
	installdata.sl.rtview.cmd_line=-dir:%RTVAPM_STARTUP%
	
	uninstalldata.sl.rtview.cmd_line=-uninstall_service
	uninstalldata.sl.rtview.cmd_line=-service:BWMONdataserver
	
	Then you may install and run the dataserver, for example, with the command
	
	rundata -properties:local -propfilter:installdata
	
	Note the environment variable %RTVAPM_STARTUP% is set by the run scripts to the 
	directory in which the script started up. 

Engines

16863: Engines should no longer incorrectly indicate NO DATA status
	In the engines tab the status of NO DATA would appear  for some engines 
	that actually have data available.  This issue appears to be related to large 
	numbers of active engines and high data volumes and has been 
	addressed with improved data buffering.
	

16943: Incorrect CPU percentage with multi-processors addressed
	In BW Monitor, the BW Engine table includes the column CPU %, defined as the 
	percent of the server's total available CPU being used by the BW Engine O/S 
	process. However the server's total available CPU is not actually available from 
	BW, so BW Monitor approximates the value using elapsed time. This algorithm did 
	not allow for the possibility that multiple processors (CPUs, cores, etc.) could 
	be available to the BW Engine, so the CPU % value could on such systems become 
	greater than 100%. This has been fixed. 

16944: Provided CPU% usage on engine icon
	BW Monitor now provides an indication on the BW engine icon to show percent CPU 
	used by each engine. 

17712: Combo boxes repositioned for easier reading
	On the process and activity pages where there are selector combo boxes for 
	processes and activities in addition to engines, the combo boxes have been 
	repositioned so that the engine box is always able to be expanded (it being the 
	longest name.) 

17876: BWM enhanced to detect and report undeployed engines
	BW Monitor has been enhanced to detect and report undeployed engines and to 
	detect newly-deployed ones. 
	
	To implement this, the BWAgentPlugin microagent will now look for undeployed or 
	newly deployed engines on an update period which defaults to one hour. This 
	period may be adjusted by editing BWAgentPlugin.hma and changing the value of the 
	new "-update" argument. The value is in seconds. On each execution the microagent 
	will check to see if the period specified by -update has passed, and if so it 
	will update the deployment data. 
	
	Note that the microagent will execute on an interval determined by the poll 
	interval of the data attachments made to its methods; this is set by the 
	substitution $bwenginePollInterval and defaults to 30 seconds. 
	

17897: Process laels in the engine summary page renamed
	On the Engine Summary Page, under Process Counts the label "Active" has been 
	changed to Running, and in the trends the label Active Procs has been changed 
	to Running Procs, to reflect the underlying BW metric, TotalRunningProcesses. 

General

17092: Server name no longer truncated in displays if 20+ chars
	The BW Monitor displays have been improved to allow for display of long 
	server names. Specifically, the width of the server icon in the all servers grid 
	view, and the width of the server drop-down listboxes has been increased, 
	and tooltips displaying the complete names have been added to the server 
	icon and all the selector drop-down listboxes.

17320: RTView for APM integration
	BW Monitor has been integrated into the RTView for APM platform and its displays 
	now follow the standards of that platform and also receive enhancements from it, 
	including 
	
	- navigation enhancements: navtree, back button
	- heatmaps with selectable metrics
	- alert indicators in tables
	- improved presentation of trend graphs
	
	In addition BW Monitor itself has been enhanced:
	
	- deltas and rate columns added for strategic data
	- totals caches added for selected activity and process data 
	- improved server and engine grid objects with trends, etc.
	- improved summary pages with deltas, rates, averages
	
	

17332: Conformance with RTView for APM standards
	The layout of objects in BW Monitor has been adjusted in various small ways to 
	conform to the visual conventions of the RTView for APM suite. 

17350: Provide indication when data updates stop
	BW Monitor will now recognize that a BW Server has become unavailable 
	or stopped sending data and will reflect this in the displays. After a 
	user-configurable length of time with no data received, the server will be 
	marked "expired", and (f desired) after another user-configurable length 
	of time the server will be removed from the displays.
	
	The length of time before expiration and the length of time before deletion 
	are specified via two new substitution variables:
	
	sub $bwServerExpirationTime:600
	sub $bwServerExpirationTimeForDelete:3600
	
	When a server is marked expired this is displayed as follows:
	
	1. In the server grid and table displays the server's status is set to 
	EXPIRED. In the grid display the server icon color changes and in the 
	table the server's row is marked with different foreground/background 
	colors.
	
	2. In the server heatmap display the server's color changes.
	
	3. All the engines belonging to that server are marked "Expired" and this 
	is reflected in the engine table, grid and heatmap displays in the same 
	manner as the server displays.
	
	4. All process and activity data belonging to the expired engines are 
	marked "Expired" and this is reflected in their displays in the same 
	manner.
	
	5. If a server is deleted then all engine, process, and activity data related 
	to it are deleted as well.

17359: BW Monitor now resizes more effectively
	The BW Monitor is now fully resizable. Where applicable, key display items will 
	expand for greater readability as the application grows in size. 

17690: Implememented auto-scale heatmaps
	BWM heatmaps now provide auto-scale and log check boxes to automatically alter 
	the selected metric color visualization. 

17710: Added microagent filter name in the all engines table
	The All Engines Tables Display has been enhanced with an "Engine Name Filter" 
	text field which allows you to select engines based on name. You may enter any 
	string which is present in the name of the engines you want to see. Wild card 
	characters are supported. If you press the 'Clear' button, the text in the 
	"Engine Name Filter:" is removed and all engines for the given Filter/Server 
	selection are shown. 
	
	In addition there is a "Show Active Only" checkbox which will hide, in the table, 
	any engines whose status is not ACTIVE, and a "Count" field which shows the 
	number of engines currently being displayed. 

17711: Drilldown from engine/server summary to engine/server table
	The server summary page and engine summary page both display alert indicator 
	lights, showing the count of alerts at each index level (server, engine, process, 
	activity). These alert indicators have been enhanced with drilldowns to new 
	displays, bw_engine_tables and bw_server_tables, which display the current alerts 
	for the selected server or engine. 

17837: Hide non-relevant columns in Engine table display
	The following columns have been removed from the All Engines Table display 
	because they repeated information already present: 
	
	Process Name
	Host
	Adapter Name
	Instance ID

17910: Server Process (Summary) pages now disabled by default
	The BW Monitor Server Processes and Server Process Summary pages are not enabled 
	by default, because (due to limitations in Tibco Hawk) the data they display is 
	not available from IBM AIX or HP-UX servers. 
	
	To enable these displays, edit bwmon_navtree.xml in the project directory and 
	uncomment the following two lines, then restart BW Monitor. 
	
	<!-- <node label="Server Processes" display="bw_server_processes"/> -->
	<!-- <node label="Server Process Summary" display="bw_server_process_summary"/> 
	--> 
	

Hawk Alerts

17893: Need way to filter out  Hawk alerts from bw_hawk_alerts display
	Hawk Alerts in BW Monitor have been enhanced as follows:
	
	1. Unwanted alerts may be filtered out of the cache data according to the alert 
	text. If you specify a regular expression filter string via the substitution 
	$hawkAlertTextFilterOut then any alerts whose text matches the expression will be 
	filtered out. The default is no filter, see see rtview.properties: 
	
	# Default filtering out string for the Hawk Alerts display 
	sl.rtview.sub=$hawkAlertTextFilterOut: 
	
	If one wants to filter out a Hawk alerts containing a given strin, then one needs 
	to declare the string to filter out between either 
	single quotes or no quotes. E.g. The following two declarations should work 
	similarly: 
	sl.rtview.sub=$hawkAlertTextFilterOut:Source
	and 
	sl.rtview.sub=$hawkAlertTextFilterOut:Source
	will filter out all Hawk Alerts in which the Alert Text string contains the 
	substring 'Source' 
	
	Note: alerts removed from the Hawk cache data will not be included in alert 
	counts and displays throughout BW Monitor 
	
	2.  The Hawk Alerts display has been enhanced with the addition of:
	(a) An Agent Filter dropdown list, by means of which you may select alerts from a 
	single agent or all agents 
	
	(b) An Alert Text Filter field, in which you may put an expression to filter on 
	the alert text. The filter field may be cleared with the associated Clear button. 
	
	Note: in this case the alerts are only filtered out in the display and are not 
	removed from the data. So in this case the alerts will be included in alert 
	counts and displays throughout BW Monitor. 

17895: Hawk alerts integration
	Hawk alerts have been integrated into BW Monitor by means of a new BW Monitor 
	alert named HawkAlert, which is triggered by Hawk alerts and includes the Hawk 
	alert text. If you enable this alert via BW Monitor Alert Admin, then Hawk alerts 
	will be included in alert counts and displays throughout BW Monitor. 

17896: Hawk Alerts Expiration
	Hawk Alerts in BW Monitor have been enhanced as follows:
	
	Alerts that have been cleared will be removed from the cache data according to 
	the expiration time set by the substitution $rtvHawkAlertClearTime. The default 
	value is 3600 seconds, see rtview.properties: 
	
	# Default time to remove cleared Hawk Alerts from table
	sl.rtview.sub=$rtvHawkAlertClearTime:3600

17907: BW data server agent now collects corrects data
	In a sender-receiver dataserver deployment with multiple senders and one 
	receiver, the state of the Hawk agents was not correctly displayed. This has been 
	fixed. 

Hawk Data Access

17846: BWMON sender dataserver doesnt send HawkAlerts table
	The Hawk Alerts table was not included in the tables that are sent by a Sender 
	Data Server. This has been corrected. 

17875: Add process Active metric from Hawk
	On the BW Monitor Process Summary display and in the All Processes table is a 
	field Active. Under some conditions of Process Engine design and execution this 
	value was showing as negative. This has been corrected. 

Processes

17852: Show Active / Most Recent Execution and Elapsed times in table
	The following columns have been added to the All Processes Table:
	
	After AverageExecution:
	
	MostRecentExecutionTime
	Execution time (in milliseconds) of the most recently completed process instance.
	
	
	After AverageElapsed:
	
	MostRecentElapsedTime
	Elapsed clock time (in milliseconds) of the most recently completed process 
	instance. 
	
	Active
	Number of processes instances created and not completed or aborted.

Scripts

17052: set_rtvapm_options.sh error removed
	Unix_RunAPMDisplayServer_DS.sh reported
	
	ERROR: cannot open <Server".rtv>
	
	to its console on startup. This has been fixed.

Servers

17316: Server metric limitations for Unix platforms addressed
	In the previous version, there were limitations for host metrics from Unix 
	systems. Some of these limitations have been resolved. The Process Heatmap is now 
	included and Free Memory is now available for Unix and HP-UX Itanium. 
	
	The following limitations still exist:
	
	AIX
	- Status will be LIMITED
	- CPU Usage, Free Memory and Virtual Memory Usage will not be available

17720: Disable deletion of expired servers
	A BW Server is "expired" when the period of time specified by the substitution 
	variable $bwserverExpirationTime has passed since data was last received from the 
	server. When a server is expired all data relating to it in the BW Monitor 
	displays is highlighted accordingly. 
	
	The default value for $bwserverExpirationTime is 75 seconds, as defined in 
	rtvapm-home/bwmon/conf/rtvapm.bwmon.properties, viz: 
	
	############################
	# CACHE / HISTORIAN SETTINGS
	#
	# Server data are considered expired after 75 seconds but are not deleted.
	#
	sl.rtview.sub=$bwserverExpirationTime:75
	
	To configure this value, copy the above line into your rtview.properties file and 
	edit it there. 
	
	Note that expired BW Servers will be removed from the displays only when the 
	relevant bw monitor data servers are restarted. 
	

17813: All Servers heatmap now drills down to the correct server
	In the BW All Servers heatmap display, when clicking on one of the squares of the 
	heatmap to drill down to the specific server summary, it didn't go to the correct 
	server display, but rather to the first server in the list. This has been fixed. 

Version 5.8g1 Release Notes

Deployment

17198: Support for multiple distributed dataservers
	RTView BW Monitor has been enhanced so that BW Monitor data servers 
	can send to and receive from each other on a network, using the 
	RTVAgent data adapter.  Typically you would configure some data 
	servers as senders and direct them to a common receiver in a 
	master-slave or hierarchical relation. This would allow you to locate BW 
	Monitor data servers close to their data sources to provide more efficient 
	data transport over a wide area.
	
	The following is included in this release:
	
	(1) New directory projects/apmbw_ds with configuration files for enabling 
	the RTVAgent sender in the data server. Only the data server is run from 
	this directory.
	
	(2) New run scripts [Unix/Win]_ RunAPMDataServerAgent.[sh/bat] in apm/bin.
	
	Configuration of the sender: 
	
	(1) In projects/apmbw_ds:
	
	(a) In OPTIONS.ini find the line sub $bwrtvAgentTarget:'localhost:5665'  
	and replace localhost with the receivers hostname.
	
	(b) Set up BW servers in HAWKOPTIONS.ini as appropriate. 
	
	(2) Run the data server using the RunAPMDataServerAgent script. Other 
	BW components may be started as usual in a data server environment, 
	e.g.  RunAPMViewer_DS, RunAPMDisplayServer_DS, etc.
	
	Configuration of the receiver:
	
	(1)  Remove from HAWKOPTIONS.ini any BW servers which have been 
	configured as senders. 
	
	(2) Run the data server as usual using the RunAPMDataServer script. 
	Other BW components may be started as usual.



Scripts
17261: make*wars.sh scripts corrected to support HP and Solaris
	On HP-UX and Solaris, running apm-home/webconf/make_apmbw_wars.sh
	resulted in several "command not found" messages for commands pushd 
	and popd. This has been corrected.




Version 5.8f1 Release Notes
BW Monitor Microagent
17002: Discover BW engines installed in all PARs
	If more than one PAR (Process Archive) were defined per deployed engine, 
	BW Monitor would not recognize them all. This has been corrected.
	



Configuration
17113: Default filters removed
	The example filter definitions provided in BW_FILTERS.xml have been 
	commented-out so they will not appear in the Filters dropdown list.
	



General
17092: Server name no longer truncated in displays if 20+ chars
	The BW Monitor displays have been improved to allow for display of long 
	server names. Specifically, the width of the server icon in the all servers grid 
	view, and the width of the server drop-down listboxes has been increased, 
	and tooltips displaying the complete names have been added to the server 
	icon and all the selector drop-down listboxes.
	




Version 5.8e1 Release Notes
Engines
16863: Engines should no longer incorrectly indicate NO DATA status
	In the engines tab the status of NO DATA would appear  for some engines 
	that actually have data available.  This issue appears to be related to large 
	numbers of active engines and high data volumes and has been 
	addressed with improved data buffering.
	



16864: Engines now showing correct status of ACTIVE when restarted
	Under certain circumstances the status of a BW engine would not show 
	ACTIVE after the engine was stopped and restarted. This has been fixed.
	



General
16865: Defined filters now work on the Servers and Hawk Alert tabs
	The Named Filters functionality on the Servers tab was working incorrectly 
	such that applying a filter would cause all data to be removed from the 
	display. This has been fixed; a named filter with a Servers section will work 
	correctly on this tab. The Named Filters dropdown has been removed from 
	the Hawk Alerts tab and replaced with a checkbox which will cause only 
	active alerts to be displayed.
	



Hawk Data Access
16875: New "Show Active Alerts" checkbox for Hawk Alerts
	The Hawk Alerts tab now has a checkbox labeled "Show Active Alerts" that 
	will filter the display to show only active alerts.
	
	



Servers
16876: Status of Discovered Servers changed to Limited
	Certain types of Hawk agents, when discovered and connected, do not 
	provide all the requested information (see BW Monitor documentation, 
	Limitations section). These have been displayed with status "UNKNOWN", 
	but this has been changed to "LIMITED" to represent the situation more 
	correctly.
	
	




Version 5.8d1 Release Notes
Deployment
16802: Thin Client no longer unresponsive
	Under certain conditions the BWM thin-client would hang after navigating 
	to several displays. This problem has been corrected.


Version 5.8c1 Release Notes
BW Monitor Microagent
16542: Premature exit when parsing error occurs has been prevented
	The BW microagent, if it encountered a fatal error parsing the files of a given 
	deployment, would skip the remainder of the deployments in that domain 
	and go on to the next domain if any. This has been corrected so it will 
	continue with the next deployment in that domain.

16543: BW microagent now distinguishes beween BW and other adapters
	The BW microagent will now search a properties file for the productType and 
	will skip the file if the value is not "BW".

16545: Parsing for the TRA file path improved
	The BW microagent will now correctly parse the executeCmd --propFile 
	argument for the TRA file path if it contains quotes or trailing parameters.

16557: Changed "-tibco" argument in .hma to "-domainhome"
	The optional argument "-tibco" supplied to the plugin microagent by the 
	.hma file, has been changed to "-domainhome". This is the path to the 
	directory containing the DomainHomes.properties file (usually 
	/tra/domain)

16647: Support blank input lines and don't reset the log
	If the DomainHomes.properties file in the Tibco configuration contained a 
	blank line (e.g. as a result of hand-editing) the microagent would log an 
	error "Error parsing input". 
	
	Additionally, if the method ResetDeploymentData was invoked more than 
	once without restarting the agent, the GetDeploymentLogEntries method 
	would report an indexing error when it was next invoked.(These methods 
	are invoked manually e.g. via the Hawk Display tool).
	
	These issues have been fixed.

Deployment
16499: Opening splash page now appears correctly  in thin client
	Previously when BW Monitor was started using the thin-client, the initial 
	display was blank.  This has been corrected.  The BW Overview display is 
	now drawn when BWM is started.

Hawk Data Access
16585: Data now only collected from domains named in configuration
	BW Monitor has been modified to collect live BusinessWorks data from only 
	the named domains defined in the Hawk Connections Tab during system 
	configuration.  Previously, if an agent was running BW Engines on multiple 
	domains, data from all domains would have been collected.

16591: Latency problems with Hawk data addressed
	BW Monitor has been modified to speed up access to data from BW 
	microagents at program startup.

Platform Support
16609: Support for BW on HP UXi on Itanium 64 bit
	BW Monitor now supports monitoring BusinessWorks installed on HP UXi 
	on Itanium 64 bit.  
	
	The following limitations exist:
	Server status is UNKNOWN
	Server Free Memory is not available
	Server Processes table is not available

16610: Windows support on 64 bit platforms
	BW Monitor now supports monitoring BusinessWorks installed on Windows 
	64 bit platforms.

Scripts
16529: Display server now defaults to daemon mode
	The BWM startup scripts have been modified to start the Display Server in 
	daemon mode, to improve performance.

16544: Historian default setting will no longer be to recreate tables
	Previously the BWM Historian was configured to automatically recreate the 
	database tables when it was restarted.  This behavior has been changed, 
	so that now the Historian will keep data from previous sessions.

Servers
16487: Changes to status of Engines on Server icons
	The calculation of the Status field for BW Engines has been updated:
	
	1. NO DATA: this status indicates that we have received deployment data 
	from the custom RTView MicroAgent, but have not received any live data 
	from TIBCO Hawk.
	
	2. ACTIVE: in BW 5.7.1 we cannot get the actual status from the 
	GetExecInfo method, due to a bug in BW.  We now identify these engines 
	as ACTIVE because we have received live data -- previously the status for 
	these engines was listed as UNKNOWN.
	
	3.  LIMITED:  this status indicates that we have received live data from 
	TIBCO, but have not received deployment data from the custom RTView 
	MicroAgent.
	
	The calculation of Active Engines shown in the BW Servers grid has been 
	updated.  The new calculation includes all Engines whose Status is 
	either ACTIVE or LIMITED.
	




Version 5.7d1 Release Notes
Engines
16511: Some engine names no longer cause bad data on Engine displays
	If the name of a BW engine name was not of a particular form, BW 
	Monitor failed to find some of its deployment data, and did not recognize 
	the actual engine name when it became active.
	
	For example, if the actual engine name were "MyDomain.MyApp.Procs" 
	then everything would work correctly, but if it were for example 
	"MyDomain.MyApp.Process Archive" then the engine displays would be 
	affected as follows:
	
	When the actual engine was stopped, the displays would have an engine 
	with the name MyDomain.MyApp.Procs, status STOPPED, and MaxBytes 
	0 due to missing deployment data. (Note this also affects the display of 
	other memory data.)
	
	When the actual engine was started, the display of 
	MyDomain.MyApp.Procs would be unchanged, and there would be a 
	second engine with name MyDomain.MyApp.Process Archive, status 
	UNKNOWN, and some live data but no deployment data, hence also 
	missing memory data.
	
	This has been fixed.
	




Version 5.7c1 Release Notes
BW Monitor Microagent
16328: RTViewBWAgent  plug-in micro-agent added
	The RTViewBWAgent is a plug-in micro-agent. It is installed in the Hawk 
	agent for a given domain. To install it:
	
	(1)  Find the files BWAgentPlugin.jar and BWAgentPlugin.hma in the lib 
	directory of your BW Monitor installation, 
	(2)  For the given domain, find the folder plugin via the path
	 /tra/domain/
	(3)  Copy the two files to the plugin folder and (re)start Hawk agent.
	
	
	You can then use Hawk Display to see the RTViewBWAgent microagent 
	and invoke its methods, GetBWDeploymentNames and 
	GetBWDeploymentMaxHeapSizes.

Engines
16018: Engine memory values now calculated using MaxBytes
	The engine memory metrics UsedBytes and PercentUsed are now 
	calculated using MaxBytes as follows:
	
	UsedBytes = MaxBytes - FreeBytes
	PercentUsed = (100*UsedBytes) / MaxBytes.

16251: BW Engines tab now displays all deployed engines
	The BW Engines tab will now display all deployed engines, even those for 
	which BW Monitor has received no data.  This feature is only available on 
	servers where the custom RTViewBWAgent Hawk microagent has been 
	installed.
	
	On the BW Engines grid, deployed engines which have not been started 
	since BW Monitor was started will appear as STOPPED.  Data metrics will 
	appear as zeroes until the engine is started and live data is received.

16388: Indication when BW Engines have Stopped
	Previously, a BW engine may have shown the status of Active when it has in 
	fact been stopped.  Now the status will go to STOPPED when the engine 
	stops.

16398: Changes to BW Engines display metrics
	Object Grid: 
	1) BW Engine icon in object grid now displays additional status values 
	STOPPED, UNKNOWN.
	2) Total KB value replaced by Max KB which is MaxBytes / 1024.
	
	Heatmap: 
	TotalBytes replaced by MaxBytes as cell size variable.
	
	Table: 
	1) TotalBytes replaced by MaxBytes.
	2) Mem Usage KBytes removed.
	3) UsedBytes and PercentUsed calculated using MaxBytes: (note PercentUsed is Long)
		UsedBytes = MaxBytes - FreeBytes
		PercentUsed = (100*UsedBytes) / MaxBytes

16399: Single Engine Summary display updates
	The Engine grid icon now displays the engine memory metric MaxBytes in KB.

General
16412: Row limit removed from tabular displays
	The per-table row limits have been removed from the tabular displays, and 
	the Display Server is now configured to run with a table paging size limit 
	(-cellsperpage:25000)
	



Hawk Data Access
16327: Improved support for TIBCO BusinessWorks 5.7.1
	In previous versions of BW Monitor, the BW Engines tab would fail to show 
	engines that were running on systems with TIBCO BusinessWorks 5.7.1 
	installed.  This has been corrected.
	



Platform Support
16424: 32 bit AIX supported added
	AIX has been added as a supported platform for BW Monitor.  
	
	Limitations:
	Metrics in the BW Servers tab are not available, but BW metrics on the 
	Engines, Processes, and Activities tabs are collected and displayed.

Scripts
16450: Display Server table limits implemented
	The Display Server  is now invoked with the following parameters:
	
	-cellsperpage:25000 
	-cellsperexport:30000 
	-cellsperreport:5000
	



Servers
16397: All BW Servers tab now shows active and deployed engine count
	The servers icon now displays the number of deployed engines and the 
	number of active engines.

16400: Connectivity indicator improved
	The detection of connectivity, as displayed by the connection icon, has been 
	improved, so that if a BW Server (an Agent capable of running BW apps) is 
	reachable but there are no engines running, the connectivity will be seen as 
	"No data" rather than "No connection".
	
	The indicator states are as follows:
	
	No Conn (red): 	No BW servers are found
	No Data (grey): 	One or more servers are found but no engines are delivering data
	Conn OK  (green):	One or more engines are delivering data.

Version 5.6c1 Release Notes
Configuration
16134: Support added for user-configurable named filters
	The BW Monitor has been enhanced with user-configurable named filters. At 
	the top left of each display is a drop-down list of available filter names (plus 
	No Filter). Each filter can operate on one or more of the fields Domain, 
	Server, Engine, Process, Activity, supplying one or more values for each 
	field. The final filter is "and"-ed across fields and "or"-ed across multiple 
	values in a field. Values may be wild-carded (with * and ?). 
	
	You can configure the filters by editing the file BWFILTERS.xml, which 
	contains commented examples.

Deployment
16178: Support improved for BW Monitor Viewer on Unix platforms
	BW Monitor Viewer is now fully supported on Unix systems.
	
	Note: when installing BW Monitor with "unzip", be sure to use the option "-a" 
	(auto-convert text files) so that executable shell scripts will be in the correct 
	format.

Engines
16052: Restarted BW engines now automatically recognized
	When an engine is stopped and restarted, BW Monitor would see that the 
	engine had stopped but would not see that it restarted. Now, it will not see 
	that it stopped: Engine status will remain RUNNING and Conn will remain 
	OK. However data will not accumulate and the trend charts will not update.
	
	When the engine restarts the engine data will update with the new values 
	and the trend charts will continue without a gap.

General
15981: Make default time range 20 minutes
	The default time range for historical trends has been changed to 20 minutes.  
	Previously the default was 2 minutes.

16066: Caches now employ configurable cache condensation
	The BW Monitor cache definitions have been updated to use the Cache 
	Condenser, in order to allow longer periods of historical data to be 
	viewed.  Several cache parameters have been made customizable 
	through the use of RTView substitution variables.
	
	By default, BW Monitor trend graphs will show 20 minutes of current raw 
	data, combined with older historical data that has been condensed to 
	show a single value for each five minute interval, up to a configurable 
	maximum number of records for each type of cache.
	
	The following substitution variables may be used to control the data 
	polling rate and cache properties for various categories of data collected 
	by BW Monitor.  Note that these variables are applied to an entire cache, 
	and not to an individual BW server, engine, process, or activity.  The 
	values listed below correspond to the default values built into the BW 
	Monitor displays.  These substitution variables are set using the 
	Configuration Utility and are stored in the file OPTIONS.ini.
	
	Server Metrics:  These substitutions control the data collected from Hawk 
	agents and displayed in the BW Servers tab.  Metrics include CPU and 
	Virtual Memory usage, as well as metrics for OS processes running on 
	each server.  The $serverPollInterval specifies, in seconds, how often 
	data is collected from each server.  The $serverRawDataRetentionSpan 
	specifies how many seconds of raw data are retained and displayed in 
	historical trends.  The $serverCondenseInterval specifies, in seconds, 
	how often the most recent raw cached data is aggregated into a single 
	record.  The $serverMaxHistoryRows specifies the maximum number of 
	records stored in the history tables for the server caches.
	
	sub $serverPollInterval:30
	sub $serverRawDataRetentionSpan:1200
	sub $serverCondenseInterval:300
	sub $serverMaxHistoryRows:100000
	
	BW Engine Metrics:  These substitutions control the data collected and 
	displayed in the BW Engines tab.  The $bwenginePollInterval specifies, 
	in seconds, how often data is collected from each engine.  The 
	$bwengineRawDataRetentionSpan specifies how many seconds of raw 
	data are retained and displayed in historical trends.  The 
	$bwengineCondenseInterval specifies, in seconds, how often the most 
	recent raw cached data is aggregated into a single record.  The 
	$bwengineMaxHistoryRows specifies the maximum number of records 
	stored in the history tables for the BW Engine cache.
	
	sub $bwenginePollInterval:30
	sub $bwengineRawDataRetentionSpan:1200
	sub $bwengineCondenseInterval:300
	sub $bwengineMaxHistoryRows:100000
	
	BW Process Metrics:  These substitutions control the data collected and 
	displayed in the BW Processes tab.  The $bwprocessPollInterval 
	specifies, in seconds, how often data is collected for each BW process.  
	The $bwprocessRawDataRetentionSpan specifies how many seconds 
	of raw data are retained and displayed in historical trends.  The 
	$bwprocessCondenseInterval specifies, in seconds, how often the most 
	recent raw cached data is aggregated into a single record.  The 
	$bwprocessMaxHistoryRows specifies the maximum number of records 
	stored in the history tables for the BW Processes cache.
	
	sub $bwprocessPollInterval:30
	sub $bwprocessRawDataRetentionSpan:1200
	sub $bwprocessCondenseInterval:300
	sub $bwprocessMaxHistoryRows:100000
	
	BW Activity Metrics:  These substitutions control the data collected and 
	displayed in the BW Activities tab.  The $bwactivityPollInterval specifies, in 
	seconds, how often data is collected for each BW activity.  The 
	$bwactivityRawDataRetentionSpan specifies how many seconds of raw 
	data are retained and displayed in historical trends.  The 
	$bwactivityCondenseInterval specifies, in seconds, how often the most 
	recent raw cached data is aggregated into a single record.  The 
	$bwactivityMaxHistoryRows specifies the maximum number of records 
	stored in the history tables for the BW Activities cache.
	
	sub $bwactivityPollInterval:30
	sub $bwactivityRawDataRetentionSpan:1200
	sub $bwactivityCondenseInterval:300
	sub $bwactivityMaxHistoryRows:100000
	
	BW Alerts Metrics:  These substitutions control the data collected and 
	displayed in the BW Alerts tab.  The $bwalertPollInterval specifies, in 
	seconds, how often BW Alert data is collected.
	
	sub $bwalertPollInterval:30

16099: Directories have changed
	The directory structure of BW Monitor has changed as follows:
	
	A lib directory has been added to the top level. This directory contains
	gmsjapm.jar and gmsjapmbw.jar, which used to be in rtview\lib.

16135: Heatmap label visibilities can now be modified
	A slider to control the visibility of labels has been added to the Heatmap 
	displays for the BW Servers, BW Engines, BW Processes, and BW Activities 
	tabs.  The maximum label nesting depth that can be shown depends on the 
	heatmap, ranging from 1 level of labels for the BW Servers heatmap to 4 
	levels of labels for the BW Activities heatmap.  When moved all the way to 
	the left, no labels are shown.  When moved all the way to the right, the 
	maximum number of label levels are shown.

16202: HawkAgentCache SQL execute query failure removed
	Previously when BW Monitor was started a SQL error message was 
	displayed in the console indicating that a table was not found in the 
	RTVHISTORY database.  This has been fixed.

Hawk Data Access
16203: Hawk data access functions display error messages at startup
	Previously when BW Monitor was started, the following error messages 
	were displayed in the console:
	
	ERROR: function , Invalid type of column 
	ERROR: function , Invalid column name 
	
	The errors did not interfere with BW Monitor operation.  In this release the 
	errors have been caught and the messages no longer appear.

Platform Support
16062: Server tab now shows UNIX servers (Solaris, HPUX, Linux)
	Previously Unix and Linux servers would not appear in the BW Servers tab.  
	This has been fixed.  The servers now appear, although memory metrics 
	are not available, so the trend graphs in the object grid and in the server 
	detail screen will not show memory metrics for these servers.

Scripts
16014: Failure with scripts on non-english Windows fixed
	Previously, the utility script Win_GetProjectDir.bat would crash when run on a Dutch 
	version of Windows.  This has been fixed.

Servers
15966: Time Range on Process Memory/CPU Detail display not initialized
	The time range for all trends in BW Monitor is controlled by a single, shared variable.  
	Setting the time range on any trend will cause all other trends to display the new time 
	range.
	
	Previously, the time range on the Process Memory / CPU Detail Trend display was not 
	linked to this shared variable.  This has been fixed.