There are several properties that can be edited through the screen.properties file, located in the install directory/Attachmate/EAI/ScreenConnectors directory. These include the ports through with the runtime server communicates with the client application, logging options, and options for running as a UNIX daemon.
After making changes in the screen.properties file, you must restart the runtime server for the changes to take effect. For information about starting the runtime server, see Starting and Stopping Run-time Servers.
| To | Set this property | Description |
|---|---|---|
| Change the RMI port | rmi.port= | Communication between the client application and the runtime engine is through an RMI registry, which by default uses port 6700. If you run more than one instance of the runtime engine on a single computer, each instance must use a unique RMI port.
You must specify the same value for this port in MCS when you configure the runtime server. |
| Specify a port for the Configuration Server object to use | rmi.cfg.port= | The runtime service creates an object called Configuration Server. This object reports the port used for the runtime engine to the RMI registry, which then directs communication between the runtime engine and the client application through that port.
If the property is not specified, or if it is set to zero, an arbitrary port number is dynamically assigned. If you are running a firewall, you may need to allocate a specific port and then configure your firewall to allow connection requests on both the RMI port and the Configuration Server port. |
| Adjust the VM heap size to handle heavy loads | runtime.vmargs= | The Runtime Service is a Java program. It may be necessary to adjust the amount of memory that is available to the Java Virtual Machine (JVM), especially on servers where a heavy load is anticipated. Pools and sessions can consume significant amounts of memory, so providing the VM with an ample heap size ensures peak performance and prevents Java OutofMemory errors.
The heap size can be tuned with command-line parameters as described in Sun's Java 2 SDK documentation for java.exe. The initial heap size is specified with the -ms<size> (or -Xms <size>) parameter. The maximum heap size is specified with the -mx<size> (or -Xmx <size>) parameter. For example, -ms32m -mx128m specifies an initial heap size of 32 MB and a maximum of 128 MB. To adjust the VM Heap size, add the -ms -mx VM parameters to the runtime.vmargs property. All operating platforms have a maximum memory per process, for example 2GB in Windows 2000 Server. This maximum memory allotment consists of both heap memory and thread stack memory. By default, 32MB is allocated to start (-Xms32m) and 512M max (-Xmx512m) for the Java VM that contains the Runtime Service. This setting maximizes the number of sessions that the run-time supports (about 3500 on Windows 2000 Server) by balancing the demand for both types of memory. Sessions use a combination of heap memory and thread stack memory. The heap memory is used to store Java objects and data. The thread stack memory is used to store local variables used by threads. If your tasks need to handle very large amounts of task data, you can increase the amount of heap memory (at the expense of thread stack memory and the maximum number of sessions). When dealing with heap memory limitations, try to reduce the amount of data that your task must deal with. For example, if a task needs to scan a very large table to return a single result, it's more efficient and scalable to have the host scan the table and return the desired result than it is to have the task collect all of the table data inside the task and use the select rule to find the desired result. |
| Set options for running as a Unix daemon | runtime.java_bin= | Location of the Java executable. |
| runtime.vmargs= | Arguments passed to the Java executable. | |
| runtime.classpath= | Class path for the Runtime Service. | |
| runtime.main_class= | Class to run (default is comm.attachmate.hps.HPS). | |
| runtime.log_file= | Log file to use (default is runtime.log). | |
| runtime.pid_file= | Process ID file. | |
| Change the wait time between stopping pools and stopping the Runtime Service | SAM.shutdown.wait.timeout= | When you stop the Runtime Service, all pools and sessions are also automatically stopped. This may mean that session activity is interrupted. Before stopping the Runtime Service, you should stop your pools to make sure that there are no active sessions. If your pools take a long time to stop, you can adjust the SAM.shutdown.wait.timeout value to change the amount of time the Runtime Service will wait before stopping. By default, this value is 30 seconds.
If you use a JVM version earlier than 1.3, this option has effect only if you're running the Runtime Service as a Windows service. |
| Change the location of the service log file | runtime.log_file= | When you run the Runtime Service as a Windows service or a Unix daemon, its activity is logged to a log file. Because log information is appended to this file, it can get quite large. |
| Change the output location for logged events | LogEvent.console= | By default, events are logged to MCS and can be viewed and filtered in the MCS view events pane. You can log to either the Runtime console window or to servicelog.txt, depending on whether your're running the Runtime Service as an application, a Windows service, or a Unix daemon by changing the value of the LogEvent.console to true. |
| Turn off logging in MCS | LogEvent.Error= LogEvent.Warning= LogEvent.Info= |
Change the value of the LogEvent options to false. |
| Provide a unique ID for this runtime server | runtime.id= | If you are logging events from multiple runtime servers to a single MCS event log, set the runtime.id property to supply a unique ID for each runtime server, for example, <runtime_id>_<task_name>.
In the Category column of the MCS event log you can use this ID to sort events by the runtime computer on which they occur. |
|
|
|
Configuring Your Run-time Environment, Overview |
|
Starting and Stopping Run-time Servers |
|
Configuring Event Logging |
 |