The following command line arguments are enabled when you run the Data Server from a Windows Command Prompt or UNIX terminal window. Options specified using command line arguments override values saved in initialization (e.g. OPTIONS.ini) files.

For command line options for your data source, refer to the Data Sources section of this documentation.

NOTE: If a command line argument contains a space or a semicolon, then the entire argument must be enclosed in quotes (e.g.: "-sub:$data:my Data").
 

Name	Description
-bg	Set the RTView application to run as a background process. When this option is specified, the GmsLauncher process and run scripts exit immediately after the RTView application is started, rather than continuing to run, thereby reducing the host system process count. However, note that: The RTView application output and error messages will not appear in the command/shell window from which it was launched. Ctrl-c cannot be used to terminate the application. NOTE: This option is only recognized on the command line and is not read from, or saved to, any RTView options (.ini) files. Example: -bg
-client_blacklist	Specifies the client access list to the Data Server. There are three access list options: client_blacklist, client_graylist and client_whitelist. Clients listed on the Blacklist are denied access to the Data Server. By default, the client access lists are empty which means that any client can connect to the Data Server. NOTE: The client access list options can be specified as Data Server command line arguments, as options in the DATASERVER.ini file, or as entries in a properties file. Specify a client hostname or IP address which may contain * characters as wildcards, or a range of IPv4 addresses in the format of n.n.n.n-n.n.n.n, where each n is a number between 0 and 255. For details, see Security. Example: run_dataserver -client_blacklist:DMZ
-client_graylist	Specifies the client access list to the Data Server. There are three access list options: client_blacklist, client_graylist and client_whitelist. Clients listed on the Graylist are permitted access to the Data Server if they provide a trusted SSL certificate. By default, the client access lists are empty which means that any client can connect to the Data Server. NOTE: Graylisting should be used only when necessary since it involves certificate management, delays from SSL handshaking, and overhead from data encryption. NOTE: The client access list options can be specified as Data Server command line arguments, as options in the DATASERVER.ini file, or as entries in a properties file. Specify a client hostname or IP address which may contain * characters as wildcards, or a range of IPv4 addresses in the format of n.n.n.n-n.n.n.n, where each n is a number between 0 and 255. For details, see Security. Example: run_dataserver -client_graylist:192.168.1.*
-client_whitelist	Specifies the client access list to the Data Server. There are three access list options: client_blacklist, client_graylist and client_whitelist. Clients listed on the Whitelist are permitted access to the Data Server, no SSL certificate is required. If the Whitelist is empty, then all clients that are not blacklisted are accepted. However, if the Whitelist has at least one entry all clients are rejected that have no match in the Whitelist or the Graylist. By default, the client access lists are empty which means that any client can connect to the Data Server. NOTE: The client access list options can be specified as Data Server command line arguments, as options in the DATASERVER.ini file, or as entries in a properties file. Specify a client hostname or IP address which may contain * characters as wildcards, or a range of IPv4 addresses in the format of n.n.n.n-n.n.n.n, where each n is a number between 0 and 255. For details, see Security. Example: run_dataserver -client_whitelist:192.168.1.* -client_whitelist:localhost
-client_write_timeout:(seconds)	Prevent a deadlock condition that can occur in abnormal situations. If the server attempts to push data to a client that is connected via socket and the corresponding write operation on the client's socket stalls for more than the specified number seconds, the server will close the client's socket. Default is 0, which means the write to a client socket will never timeout. This timeout avoids the potential for deadlock with other threads in the server that may be trying to access the same data table that was locked while being pushed to the client. The write to the client's socket may stall because of networking problems, or a deadlock or other error in the client that prevents it from reading its incoming data. Example: run_dataserver -client_write_timeout:(60)
-daemon	Run the Data Server as a daemon process. Example: run_dataserver -daemon
-dataout:(path)	Set the path of the XML output to a directory other than the local directory. You can specify both an absolute path or a relative path. Double quotes are required if the path contains spaces. Example: -dataout:"c:\rtview files\rtvdata.xml"
-exit_on_out_of_memory	Force the Data Server to terminate when an OutOfMemoryException occurs. This option is intended for use in a HA deployment where a backup server is available, otherwise the process may continue to run in a crippled state and prevent the backup from taking over. For example, if the Data Server experiences an OutOfMemoryException it may still remain connected to its clients, preventing failover, but may stop pushing any data to the clients. NOTE: The Data Server is not automatically restarted by this option and must be restarted manually. Example: -exit_on_out_of_memory
filename	Add a data configuration (.rtv) file to the Data Server. Example: run_dataserver config.rtv
-group_initial_wait:(number of seconds)	This argument is used for the backup server in a high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode. For an example of how to configure a server group on the command line, see Server Group Configuration Example. Use this argument to lengthen the wait time for the backup server to connect to the group's primary server at startup. This prevents a failure when the primary and backup server are both started at nearly the same time and the backup server attempts to connect to the primary server before it is connection ready.   Specify the amount of time (in seconds) that the backup server waits at startup for a connection to the primary. The default is zero (0). This argument is only used for the backup server. A value of 30 (seconds) is typically used. Example: -group_initial_wait:30
-group_member:(hostname:port)	This argument is used, in conjunction with the -group_priority argument, to designate the primary and backup servers for a high availability (HA)server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode. Specify the hostname and port number of the other Data Server in this group. That is, when launching the primary server in the group, use the -group_member option to specify the hostname and port number of the backup server in the group. Conversely, when launching the backup server in the group, use the -group_member option to specify the hostname and port number of the primary server in the group. If a hostname is specified without a port number, port 3278 is assumed. Do not specify a URL for the rtvdata servlet. Specifying the -group_member argument mitigates the need to specify the -standby:warm option. The server remains in standby mode until the primary server is determined. If the -group_member argument is specified and -group_priority is not, the -group_priority value defaults to a value of 1 (the lowest priority). Example: -group_member:otherhost:3278 Server Group Configuration Example The following command line examples illustrate how to use all the server group command line options (-group_member, -group_priority, -group_initial_wait and -group_timeout arguments) to run Data Servers in a server group. In this example, one Data Server runs on host A and is the primary, another runs on host B and is the backup. Both servers use port 5555. # command line for the primary server, executed on host A run_dataserver -daemon -port:5555 -group_priority:2 -group_member:B:5555 # command line for the backup server, executed on host B run_dataserver -daemon -port:5555 -group_priority:1 -group_member:A:5555 -group_initial_wait:30 -group_timeout:20
-group_ping_timeout:(number of seconds)	This argument is used for the backup server in a high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode. For an example of how to configure a server group on the command line, see Server Group Configuration Example. The primary Data Server sends a ping message to the backup server every 5 seconds. The group_ping_timeout option determines the amount of time (in seconds) the backup server waits for a ping from the primary server before it assumes the primary server failed and takes over as primary. The default value is 30 seconds and 30 is also the minimum non-zero value. A value of 0 (zero) disables the ping timeout feature entirely. This timeout argument is intended to detect rare cases where the primary Data Server is running and connected to the backup server and the primary server becomes unresponsive. If the primary Data Server terminates or the host on which it is running shuts down, the backup server detects this immediately regardless of the value of the group_ping_timeout or group_timeout properties, and takes over as the primary. Example: -group_ping_timeout:30
-group_priority:(integer)	This argument is used, in conjunction with the -group_member argument, to designate the primary and backup servers for a high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode. For an example of how to configure a server group on the command line, see Server Group Configuration Example. Specify the priority of the Data Server, where a value of 1 is the lowest priority. A larger value assigns a higher priority. The running server in the pair with the highest priority becomes the primary server. For example, let us say we have two redundant Data Servers, one running on host A and another running on host B. The server on host A is normally the primary server and the server on host B is the backup server. In this case, we set the server's group_priority value for host A to 2 and the server's group_priority value for host B to 1. The server on host A is designated as the primary server. The server on host B is designated as the backup server. The -group_priority defaults to a value of 1 (the lowest priority) if the group_member property is specified and the -group_priority is not specified. Example: -group_priority:2
-group_standby_mode	This argument is used, in conjunction with the -group_member argument, to configure the behavior of backup Data Servers in a redundant high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode. For an example of how to configure a server group on the command line, see Server Group Configuration Example. There are two modes for this argument: passive: The backup server does not activate the RTView global, cache, or alert data sources at startup. In this mode, the backup server only activates those data sources if it leaves standby mode because the primary server is unavailable. When the primary server is available again, the backup server returns to passive standby mode by deactivating the alert, cache, and global data sources. NOTE: Since the passive standby mode activates several data sources during the failover process, cache data can be missed (which the active standby mode avoids). active: The backup server activates the global and cache data sources at startup and begins collecting and storing data in caches as configured in the global and cache definition files. However, the backup server does not activate the alert data source at startup. In this mode, the backup server only activates the alert data source when if it leaves standby mode because the primary server is unavailable. When the primary server is available again, the backup server returns to active standby mode by deactivating the alert data source, and leaving the global and cache data sources activated. Since the active standby mode activates only one data source, the alert data source, during the failover process, cache data is less likely to be missed. There is some cost associated with active standby mode because both the primary and backup server collect and store data in caches. For example, if a cache definition file defines SQL queries to collect data, in active standby mode both servers perform those SQL queries. Whereas in passive standby mode only the primary server performs the queries. NOTE: the alert data source is inactive in the backup server in both active and passive standby mode, to avoid generation of duplicate alerts by the primary and the backup servers. If no value is specified the default value is passive. The group_standby_mode property can be also be specified as follows, where X is either passive or active: DATASERVER.ini: group_standby_mode X In a properties file: sl.rtview.dataserver.group_standby_mode=X Example: run_dataserver -group_standby_mode:active
-group_timeout:(number of seconds)	This argument is used for the backup server in a high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode. For an example of how to configure a server group on the command line, see Server Group Configuration Example. Specify the amount of time (in seconds) for the backup server to wait for a read and write operation on the socket connection between the primary and backup server. The default is 5 seconds. In most cases, if the primary server terminates or the host on which it is running is shut down, the backup server detects this immediately. This timeout argument is intended to detect failures where the connection remains open but stalls, or the server is unresponsive. Example: -group_timeout:10
-jmxport:(port number)	The port number to use to expose JMX methods to monitor and manage the Data Server. There is no default port. If not specified, these JMX methods will not be accessible. Example: -jmxport:9997
kill_dataserver	Stop the Data Server. A value of 0 on success and a value of 1 on failure. By default, the Data Server running on port 9020 is stopped. If you have NOT specified the jmxport property for the Data Server in the appropriate properties file you must specify it using the command line option -jmxport:xxxx (where xxxx is the port number) with run_dataserver in order to run kill_dataserver. For example, kill_dataserver -port:9995 shuts down the Data Server on the local host which was started with the -jmxport property set to 9995. NOTE: When the default port 9020 is NOT used, the port must be specified for both the run_dataserver and kill_dataserver commands. Values: -host   The name of the host. The default value is localhost. This value is overridden when -url is specified after it. Example: -host:localhost       -port          The port number for the Data Server. The default value is 9020. This value is overridden when -url is specified after it. Example: -port:9020       -silent   Specifies not to print out the progress of low level operations. -silent and -verbose are mutually exclusive. Example: -silent       -user   The user name for accessing the JMX Mbean with authentication. If you specify -user, also specify -password. Example: -user:fred       -password   The password for accessing the JMX Mbean with authentication. If you specify -password, also specify -user. Example: -password:secret       -url   The URL for accessing the (remote) JMX Mbean. If you specify -url, it must not contain spaces. URL strings are always used internally. Specifying -url overrides the use of –host and -port. The substitutions are similar to the following example.  Example: -url:service:jmx:rmi:///jndi/rmi://localhost:9995/jmxrmi       -verbose   Specifies to print out the progress of low level operations. -silent and -verbose are mutually exclusive. Example: kill_dataserver -port:9995
-log4j	Turns on Log4j logging for the RTView application. By default, RTView processes (Builder, Viewer, Data Server, Display Server, or Historian) print log messages to the console. To obtain log files, you redirect the RTView application output and error streams to a log file using Log4j. After executing this command, the first time-stamped row in the log file appears as follows: 2012-02-02 14:00:54,693 INFO – [rtview] Log4j is being used with sl.log4j.properties as the configuration file.   When Log4j is not in use, the first time-stamped row in the log file appears as follows: 2012-02-03 10:40:31.866 [rtview] Logging redirected for System.out and System.err. Log4j is not in use. (Note the missing INFO column when Log4j is not in use.) For example: run_dataserver –log4j run_dataserver –log4j –log4jlevel:INFO –showlogcat To run an RTView application as a background process using the -bg command line argument, use the sl-bg.log4j.properties configuration file (which only outputs to a log file rather than to a console). -bg (background) example: run_dataserver –bg –log4j –log4jprops:sl-bg.log4j.properties NOTE: The logging method from previous versions of RTView does not use Log4j. This previous method of logging is enabled with -logfile and –logdir and is still supported. Do not use both the previous logging method and Log4j or you receive the following error message: ERROR: log4j configuration ERROR - com.sl.rtview.useLog4j is set to true but -logfile redirection is in use. Log4j will not be used.
	-showlogcat		Turns on the Category column in the log file output. When not in use, the Category column is not shown in the log file. For example: -showlogcat
	-log4jprops		Specify the .properties file to use to format the Log4j log file. By default, sl.log4j.properties is used. Use this to provide a different property file name. The .properties file is searched for inside a .jar/.war file, then searched for in the current directory, and lastly searched for in the %RTV_HOME%/lib directory. The filename can have a path preceding it. For example, C:\mydir\my.log4j.properties. For example: -log4jprops:mylogfile.properties
	-log4jlevel		Specify the Log4j Level. INFO is used by default. Valid values are: FATAL:  Indicates a severe error that likely causes the application to abort. ERROR: Indicates an event that might not cause the application to abort. WARN: Indicates a potentially harmful event. DEBUG: Indicates detailed informational about events for debugging the application. INFO: Indicates informational messages about the progress of the application at coarse-grained level. For example: -log4jlevel:INFO
-logdir	Specify to prefix the log file name that is set in the -logfile option to the directory name in which the log file is stored. If the -logfile option is not specified, this option is ignored. NOTE: This option is only recognized on the command line and is not read from, or saved to, any RTView options (.ini) files. Example: -logdir:ABCcompany
-logfile:(filename)	Specify the redirection of output and error messages to a file. The RTView application output and error message streams are redirected to the specified file. The file is created if it does not exist. By default, if the file does exist, its previous contents are cleared. If the name of the log file contains the string DDDD (four upper case D characters), the string is replaced with the current local date and time using the format yyMMdd_HHmmss. For example, if we execute the following command on Sep 27 2012 at 3:55:43 PM: run_dataserver -logfile:DataServer_DDDD.log a log file named DataServer_120927_155543.log is produced. In most cases, this is a unique filename so that the previous log file, if any, remains unchanged. Over time, a large number of log files can accumulate so it is advisable to periodically purge the old files. On Linux, the logrotate utility can be used to automate this. NOTE: The -logfile option is only recognized on the command line and is not read from, or saved to, any RTView options (.ini) files. Example: run_dataserver -logfile:DataServer.log
	-logappend	Appends new log file output to the previous file content. That is, if the dataserver.log file already exists, output from the new log process is added to the file, preserving pre-existing content. The file size can grow quite large so it is advisable to periodically rotate the file. On Linux, the logrotate utility can be used to automate this. For example: run_dataserver -logfile:DataServer.log -logappend
-passclientlogin	Pass RTView login information into all data sources that have the Use Client Credentials option enabled. NOTE: Some data sources do not support this feature. For information on Application Options for your data source, refer to the Data Sources section of this documentation. Example: -passclientlogin
-port:(port number)	Specify port when Data Server is set to output data via socket. Default is 3278. Example: run_dataserver -socket -port:8723
-processName	Specify to identify applications running as background processes. This option tags a unique identifier onto RTView server instances, enabling you to differentiate between multiple instances of those RTView applications. This option allows you to stop a particular instance without eliminating the other instances. If no process name is specified, the RTView application name is used as the process name. For example, run_builder-processName:XX adds the following JVM option to the Java call: -DPROCESS_NAME=XX Where XX is the value you specified for the -processName argument. NOTE: Values with spaces cannot be used for this option on Unix. Example: -processName:XX
-resizemode:(mode)	Globally controls object layout when a display window is resized. It is also possible to set a specific Resize Mode for each particular display (.rtv) file using the Background Properties dialog. In the Display Builder, the selected Resize Mode is only applied to drill down windows. The main window of the Display Builder is always in Crop mode. All three resize modes support zooming the display (right-click -> zoom). In both Scale and Layout modes if the window is resized while the display is zoomed, then the resize will further zoom the display. Values:   crop When the window is resized, the display stays the same size. If the window is bigger than the display, empty space will show around the display. If the window is smaller than the display, scrollbars will be added. The window is not forced to maintain its aspect ratio. This is the default for the Thin Client. scale When the window is resized, the display and all of the objects in it are scaled to fit the available space. The window is forced to maintain its aspect ratio. This is the default for the Display Builder, Display Viewer Application and Display Viewer Applet. layout When the window is resized, the display is resized to fit the available space. The objects in the display are positioned according to their anchor and dock properties. The window is not forced to maintain its aspect ratio. Objects that are not docked or anchored will move relative to their offset from the top left corner of the display. For example, if the object is centered on the display, the object will move 50% of the resize amount. If the object is centered at 3/4 of the display, it will move 75% of the resize amount. Example: -resizemode:layout
-sendalldata	Send all data over the socket regardless of whether or not it has been updated.  Example: -sendalldata
-socket	Set the Data Server to output data via socket. Example: run_dataserver -socket
-standby:warm	Run a backup Data Server without the overhead of maintaining the Alert and Cache data sources. The following actions will be delayed until the backup server has become the primary: Loading definition files (i.e. Global, Alert, Cache) Preloading display files specified in initialization (.ini) files or on the command line NOTE: Although the -standby:warm option reduces overhead because data sources do not provide data until a failover, it is important to note that Alert and Cache data definitions will not start collecting data until the first client connects. Therefore, any previous alert state or cached data from the primary server will not be available to the backup. Example: run_dataserver -standby:warm
-sub:(substring:subvalue)	Add a substitution string/value pair. Multiple substitution pairs can be specified on the command line.  NOTE: Substitution strings cannot contain the following:   : | . tab space , ; = ? > ' " ? / \ { } [ ] ( ) If your substitution value contains single quotes, you must escape them using a /. Example: -sub:$data:myData -sub:$filter:Plant=/'SanFrancisco/'
-timezone	Set the default timezone for interpreting and displaying dates. Include a Java timezone ID or a custom ID, such as "GMT-8:00".  Unrecognized IDs will be treated as GMT.  If you run the RTView Builder with a valid timezone parameter and then save Application Options, the timezone information will be persisted. To prevent the persisted timezone value from being used, pass "none" as the timezone ID. Example: -timezone:US/Eastern  -timezone:none
-u(milliseconds)	Set update rate in milliseconds. Default is 2000. Example: -u5000 (updates every 5 seconds)
-verbose	Specifies to print out the progress of low level operations. -silent and -verbose are mutually exclusive. Example: -verbose

Options Enabled with Alerts
In addition to the General Options, the following command line arguments are enabled with the Alert data source.
 

Name	Description
-actionauditdb:(database)	Specifies name of a database connection, as defined on the SQL tab, in which to store alert actions audit information. Example: -actionauditdb:ALERTBD
-actionaudittable:(table)	Specifies name of the table in the Alert Action Audit Database in which to store the alert actions audit information. Example: -actionaudittable:ACTION_AUDIT_TABLE
-alertcleartime:(number of seconds)	Specifies the rate, in seconds, to remove cleared alerts. Example: -alertcleartime:3
-alertds:alertdef:(filename)	Adds an alert definition file. Cannot specify substitutions. To specify substitutions, use the Application Options dialog. Example: -alertds:alertdef:myalerts.rtv
-alertds:enabled:(true or false)	Enables/disables all alerts in the active alert definition files. Example: -alertds:enabled:false
-alertds:history:(size of table)	Sets the number of rows that are stored in the AlertTable. Example: -alertds:history:1000
-alertinitdelay:(number of seconds)	Specifies the duration, in seconds, to wait after startup to begin executing alerts. Example: -alertinitdelay:5
-cleansettingstable:(true or false)	If true, delete entries from the Alert Settings Table for alert names that are not defined in RTView. NOTE: This is done at startup after alert configuration files are processed and all of the alerts are loaded. Example: -cleansettingstable:true
-enableactionaudit:(true or false)	If true and configured, alert actions will be stored to the specified database table. Example: -enableactionaudit:true
-ignorelutforcount:(true or false)	If true, the AlertTable Count column increments for an alert when new data is received even if the Last Update Time has not changed. This can cause invalid Counts for alerts attached to caches. If false or not specified, the AlertTable Count column increments for an alert only if the Last Update Time has also updated. This is the default behavior. Example: -ignorelutforcount:true
-lutupdatesnewdata:(true or false)	Enables\disables updates to the AlertTable when New Data Only is selected and to the alert persistence database when the only columns that contain changes for that row are Last Update Time and Count. By default, the Last Update Time and Count columns are not tracked by the Row Update Time column. To track the updates of the two columns in the Row Update Time column, use the -lutupdatesnewdata command line option. Example: -lutupdatesnewdata:true
-multipleindexdelim:(string)	For alerts with multiple index columns, create a unique alert index by concatenating all of the index column values. Value can be any string, except the following: comma (,) semi-colon (;), or empty string. Default is tilde (~). Example: -multipleindexdelim:~
-persistInitDelayTime:(number of seconds)	Specify the amount of time, in seconds, to delay a backup Data Server from reading the alert persistence database during a failover. The default is 5 seconds. Increase the amount of time if the persistence database is slow or if you expect a large number of alerts to change on each update period. Otherwise, there might not be enough time for the failing Data Server to write all the alerts to the database before the backup server reads them. NOTE: Even with high availability configurations, there are cases in which some alerts might not be persisted. For example: The persistence database fails. In this case, alerts cannot be written to, or read from, the database. If a failover occurs while the database is down, the backup server will not be able to read persisted alerts from the database. This will also happen if persistence is configured to use a Persistence Data Server to access the database, and the Persistence Data Server is down during failover. The Alert Server is terminated in a non-orderly shutdown. Alerts are written out once per update period and once during orderly termination. If there is a non-orderly shutdown, some alerts might not be written to the database. In cases where alerts are not persisted, the new primary Data Server generates new alerts if the data is still in an alert state. The new primary Data Server might also re-use ID's that were used by the failed Data Server. Example: -persistInitDelayTime:10
-purgepersistedalerts	Clears all alerts for the alert engine from the alert persistence database on startup and no persisted alerts will be loaded. NOTE: If you are persisting alerts for more than one alert engine in the same database, alerts for other alert engines will not be removed.
-printssawarnings:(true or false)	If false, the Self Service Alerts warnings about extra unmapped thresholds will be suppressed. NOTE: This option only applies to Self Service Alerts. Example: -printssawarnings:false