| 
 Command Line
Options: Display Builder and 
Display Viewer
 The
following command line arguments are enabled when you run 
the Display Builder
or
Display Viewer 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
 |  
| -confirm:(policy
value) | Set
the confirm policy for all commands, overriding the confirm policy on individual
objects. Default is 0. Values:
-1 - do not confirm any commands
 1 - confirm all commands
 0 - follow individual
object confirm policy
 
 Example:
 -confirm:-1
 |  
| -customwindowtitle:(title) | Specify a custom window title. 
To specify an empty window title, enter 
a single space. By default, window titles contain the 
          name of the application followed by the name of the display (.rtv) 
file (e.g. RTView mydisplay.rtv). 
          A Custom Window Title: Example:-customWindowTitle:myTitle
 |  
| -dataserver: |  
| (filename) | Read data from Data Server output file
instead of directly from data sources .If no file name is specified, default
output file (rtvdata.xml) will be used. If necessary, include local
directory path or http URL. 
 Example:
 -dataserver:rtvdata.xml
 |  
| remote:primary,backup1 | Read data from Data 
Server instead of directly from data sources. Specify primary and backup servers. If no host is specified, local host
will be used. If no port is specified, default port (3278) will be used. NOTE: Designation of a backup server is optional; one or multiple backup servers can 
be specified.
 Example:
 -dataserver:remote:host:8723,host:8080
 |  
| remote:http://host:port/rtvdata,http://host:port/rtvdata_backup1   | Read data from Data Server via servlet instead of 
directly from data sources. Specify primary and backup servers. The host is web server hosting
the servlet. The port is port used by the web server. NOTE: Designation of a 
backup server is optional; one or multiple backup servers can be specified.
 Example:
 -dataserver:remote:http://host:8723/rtvdata,http://host:8080/rtvdata_backup
 |  
| name=Name;connect=primary,backup1 | Specify 
primary and backup named data server(s). The name is the Name specified when this 
data server was configured and connect is either 
host:port
or, for servlet, 
http://host:port/rtvdata.  NOTE: 
Designation of a backup server is optional; one or multiple backup servers can 
be specified. Example:-dataserver:name=MyDataServer;connect=localhost:56789,host:8080
 -dataserver:name=London;connect=https://londonServer:8080/rtvdata,http://host:8080/rtvdata_backup
 |  
| -dsenable:(dskey) | Enable data source(s) for data 
attachments and defined commands that have been configured to bypass data being 
redirected through the specified data server(s). 
The
dskey is the abbreviation for the data source as listed in the Attach to 
Data and Define Command drop down menus, but in all lower case. Example:-dsenable:sql
 |  
| filename | Open
a specific file in the Display Builder or Display Viewer. NOTE: If
your login
doesn't allow you to view a particular display, the display will not open
when you use the filename option. 
 Example:
 sample.rtv
 |  
| -fxreplace | Replace all Fx graphs with standard 
graphs in display (.rtv) files opened in the in the Display Builder and/or 
Display Viewer Application. Example:-fxreplace
 NOTE: The 
fxreplace option can 
also be specified as true in the initialization file OPTIONS.ini 
file. Options specified using command line arguments override values 
saved in initialization files. |  
| -historytablename:(tablename) | Specify
the table name (e.g., MY_TABLE) to use when loading historical data into
graphs. NOTE: Table names cannot contain spaces. 
 Example:
 -historytablename:MY_TABLE
 |  
| -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_builder –log4j
 run_builder –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. 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. You can also use Log4j configuration files in 
the XML format. For example, log4j.xml. For details, see 
http://wiki.apache.org/logging-log4j/Log4jXmlFormat. For example: -log4jprops:mylog4jfile.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:(dirname) | 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
 |  
| -login | Turns
on role based security. A login dialog will come up at startup. 
 Example:
 -login
 |  
| -max_displays_in_cache | Sets the maximum number of display (.rtv) files with composite objects to cache. 
Default is 5. If value is set to 0, no 
displays are cached. Example:-max_displays_in_cache:50
 |  
| -noedit | Display
Builder only. Run with editing disabled. 
 Example:
 -noedit
 |  
| -nohistory | Supress
historical data in graphs. 
 Example:
 -nohistory
 |  
| -nomenus | Display
Viewer only. Run without menus. 
 Example:
 -nomenus
 |  
| -nosingleclick | Disables
the default setting. Double-click to open drill down windows or execute
commands. NOTE: This option applies to the Display Viewer only. 
 Example:
 -nosingleclick
 |  
| -panelconfig:(filename) | Specify
the name of the panel configuration file for Multiple
Display Panels. 
 Example:
 -panelconfig:PANELS_GRID.ini
 |  
| -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
 |  
| -resetlayout | Display
Builder only. Starts with the default window layout. 
 Example:
 -resetlayout
 |  
| -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
 |  
| -rtvpass | If
login
is enabled, specify the password in plain text to use for the login. This
parameter must be used in conjunction with rtvuser and will bypass the
login dialog. If the rtvrole parameter is not specified for a user with
multiple roles, the first role will be used.  Use the rtvsign parameter
instead to specify an encoded user name and password. NOTE: If the user name or password
specified is not valid, the login dialog will appear.
 
 Example:
 -rtvpass:admin
 |  
| -rtvrole | If
login
is enabled, specify the role to use for the login. This parameter must
be used with rtvsign or rtvuser and rtvpass. If this parameter is not specified
for a user with multiple roles, the first role will be used. 
 Example:
 -rtvrole:admin
 |  
| -rtvsign | If
login
is enabled, specify an encoded user name and password to use for the login,
and bypass the login dialog. Contact SL Technical Support at support@sl.com
to request a copy of the utility to create the encoded strings. If the
rtvrole parameter is not specified for a user with multiple roles, the
first role will be used. NOTE: If the user name or password
specified is not valid, the login dialog will appear.
 
 Example:
 -rtvsign:8I559A5NA8A5864J6J924N0B2
 |  
| -rtvuser | If
login
is enabled, specify the user name in plain text to use for the login. This
parameter must be used in conjunction with rtvpass and will bypass the
login dialog. If the rtvrole parameter is not specified for a user with
multiple roles, the first role will be used.  Use the rtvsign parameter
instead to specify an encoded user name and password. NOTE: If the user
name or password specified is not valid, the login dialog will appear. 
 Example:
 -rtvuser:admin
 |  
| -saveusers | Saves
the user definition file with encoded passwords. The file is only saved
if you are logged in in the admin role and you are not using the Custom
User Manager. 
 Example:
 -saveusers
 |  
| -singleclick | Single-click
to open drill down windows or execute commands. This is the default setting.
NOTE: This option applies to the Display Viewer only. 
 Example:
 -singleclick
 |  
| -stylesheet:(filename)   | Specify style sheet(s) to apply to all displays in your applications. NOTE: Style sheets are 
applied at startup. If you edit a style sheet, then you need 
to restart. Example:-stylesheet:rtv_darkstyles.rts
 When multiple style sheet (.rts) files are 
applied, they are 
processed in the order specified. Therefore if the same property is specified in 
multiple style sheets, the value in the last style sheet applied (e.g. 
stylesheet3.rts) will take precedence. Example:-stylesheet:stylesheet1.rts,stylesheet2.rts,stylesheet3.rts.
 |  
| -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:$1:myValue
 -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)
 |  
 
   Options Enabled with AlertsIn 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 (;), orempty 
    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
 |  |