On Windows, if not set, TMPDIR will default to the value of the TEMP environment variable setting; if one does

not exist or if it is invalid, TMPDIR will be set to the same directory as MATRIXINSTALL. On UNIX there is no default setting for TMPDIR, but the Live Collaboration kernel will use /usr/tmp if not set. MX_CLASSPATH contains the path to the Java compiler that is specified during the ENOVIA Live Collaboration installation. It is used by the Studio Modeling Platform and the ENOVIA Live Collaboration Server service when starting the Java Virtual Machine (JVM) for both compiling and executing JPOs. With the Studio Modeling Platform, if you are running JPOs that are provided with ENOVIA Businss Process Services or other ENOVIA products, MX_CLASSPATH must include the path to the Business Process Services jar files (you should have all Studio Modeling Platform clients copy all the jar files to their ENOVIA_INSTALL\java\classes directory (or the ENOVIAHOME/java/classes directory on UNIX) to ensure they have any file theyll need). ComputedClassPath is a routine called by rmireg in RMI non-RIP setups that builds the classpath by combining the environment classpath + MX_CLASSPATH + all .jar files and all .zip files in each directory listed in MX_CLASSPATH. On Windows, if the Computed Class Path exceeds 2048 bytes, errors will occur in the application server or ENOVIA Live Collaboration Server service. If classpath errors occur due to this Windows limitation, you should remove any references to unnecessary jar or zip files in MX_CLASSPATH.

FlashDB variables
FlashDB is a next generation caching technology that improves the stability and scalability of the ENOVIA Live Collaboration Server. It replaces the c-tree engine (Turbocache) used in Matrix since Version 7 with a more modern design. Stability improvements are achieved limiting in-process memory use for caching database information and using an embedded database on disk for working with large data sets that require more memory. Also, FlashDB uses background threads for database reads and writes, taking advantage of multi/hyper threaded machines, thereby improving scalability. The following variables are used to configure FlashDB. MX_FLASH_PATH sets the directory that KeyDB uses to store its temporary files. Installation programs for the Live Collaboration server set this to SERVER_HOME/ mxcache and for Studio Modeling Platform to MATRIXHOME/mxcache. Subdirectories beginning with flash (followed by 20 hex digits) are created to hold each KeyDB instance, one for each session. A KeyDB instance is just a set of flat files, so the depth of the directory tree is the depth of MX_FLASH_PATH + 1. On UNIX servers, the mxcache directory is given 770 permissions (drwxrwx---) by default. For the Studio Modeling Platform on UNIX, the permissions are set to 777 (drwxrwxrwx). Permissions can be adjusted as appropriate for your environment. For the Studio Modeling Platform, this directory is cleaned up automatically when the client exits. For the Live Collaboration server, the files are typically left behind when the server exits. A purge of this directory should be implemented at regular intervals to avoid waste of excessive disk space. Each application server should have a separate setting for MX_FLASH_PATH to allow these temporary files to be cleaned up as part of server startup and/or server maintenance, similar to how log files are maintained on multiple servers.

198

ENOVIA Live Collaboration Installation Guide

For the ENOVIA Live Collaboration Server, there must be ample disk space available at this directory location for these temporary files. The requirement will vary, but a good starting point is to assume you will need 10% of the diskspace used by the database tablespaces. MX_HYPER_THREADED may be set to false in a server environment to turn off the use of a background thread for communication to the database server. The default is true. The default allows Flash to take advantage of multi-cpus during the processing of a single transaction. This setting is ignored by the Studio Modeling Platform, but is always false. By following best practices (especially in the definition of queries and expands) you should be able to avoid the need for the server to handle result sets so large that they need to use disk I/O for most interactive operations. Any interactive operation that has high memory requirements should be reviewed to reduce the size of the data set. However, recognizing that there are use cases (such as report generation) that must process extremely large datasets, FlashDB provides some controls on how much memory should be used to cache database rows to process requests. If these limits are exceeded, FlashDB will use local disk files for temporary storage of such data, so correctly setting these limits can be important to prevent two serious consequences of excessive memory consumption: If memory usage reaches the MX_MEMORY_SYSTEM_LIMIT, ENOVIA Live Collaboration will start to produce insufficient memory errors and abort transactions. See Memory variables below. If the memory usage reaches the operating system limit, the process will shutdown.

By default, FlashDB does not use disk space for caching.

Memory variables
The following memory settings should be configured for your environment based on installed server memory. Thread limits should be emphasized over system limits so only long running operations are affected. As a best practice to increase server stability, data should be paged to disk. Paging reduces in-process memory usage for large datasets. If you periodically see insufficient memory errors in your mxtrace log, you need to re-adjusted these settings to support larger in-process memory usage. MX_CACHE_SYSTEM_LIMIT sets a threshhold on memory consumption for all threads, before using KeyDB. If the number of bytes of in-process memory being used by all active sessions exceeds this setting, FlashDB will start paging the database rows for all sessions to disk. The default is 0, meaning unlimited, so no paging will occur. MX_CACHE_SYSTEM_LIMIT should be set to no more than 80% of MX_MEMORY_SYSTEM_LIMIT, in order to force paging to disk to occur BEFORE the system memory limit is reached. MX_CACHE_THREAD_LIMIT applies to a single thread only. If the number of bytes of in-process memory being used by a single session exceeds this setting, FlashDB will start paging the database rows for that single session to disk. No other threads are affected. The default is 0, meaning unlimited, so no paging will occur. MX_CACHE_THREAD_LIMIT should be set somewhat lower than MX_CACHE_SYSTEM_LIMIT to minimize the likelihood that a single thread, processing a large request, will affect the performance of other threads by consuming all the memory. Use of this setting means that greedy threads will page data to disk,

Chapter 10: Configuring ENOVIA Live Collaboration

199

thereby slowing their processing, but also leaving more memory available for other threads to use. A reasonable setting is 50% of the value of MX_MEMORY_SYSTEM_LIMIT. MX_MEMORY_SYSTEM_LIMIT is meant to be the high water mark of allowable memory allocation for the native Live Collaboration kernel. The ENOVIA Live Collaboration memory manager tracks the number of bytes allocated and will issue warnings for every allocation over the MX_MEMORY_SYSTEM_LIMIT. There are several areas in the Live Collaboration kernel that will also look for allocations over the MX_MEMORY_SYSTEM_LIMIT and abort the transaction. These checks are places in functional areas that are known to be memory intensive (database rowset loading, queries, expands and history lookups). The goal is to have the Live Collaboration kernel abort the transaction that is consuming large amounts of memory while allowing the other threads to continue working. MX_MEMORY_THREAD_LIMIT sets the maximum amount of memory that may be used for a single ENOVIA Live Collaboration thread. The default is 1GB. Should allocation attempts be made beyond this size, warning messages will be written to the server log that identify the program file name and line number.

Optional Variables

The following variables are not required to be set in order for ENOVIA Live Collaboration to function. When the variable is not explicitly set in the environment, ENOVIA Live Collaboration uses the default values. If required, these values should be added to the [matrix] section of the .ini file (or for UNIX, the startup script). USER can be used with another optional variable, MX_HOME_VAULT, to let you set a default context for ENOVIA Live Collaboration for Windows. USER is the default user name and MX_HOME_VAULT is your default vault. If you are using Windows, when a Studio Modeling Platform application is opened, the context window comes up with the user name as it appears in SYSTEM.INI, unless the USER variable is set here. HOME is your default home directory. FINDLIMIT sets the default limit field in ENOVIA Live Collaboration Find window. Defaults to 0 or no limit. Does not affect MQL queries. The results of some queries will load faster in the details view if a limit is specified. Setting FINDLIMIT allows you to establish a default value to optimize performance in case no limit is set in the query. When limits are set in the query, this value is ignored, and the new value does not change this setting. To optimize performance, but still find all objects that meet the criteria, you may want to make this value very large, for example, FINDLIMIT=100000. MQLWINDOWDISPLAY when set to true, displays an MQL window when running eMatrixMQL/MQLIO that may be used to diagnose and debug these programs and applications. The default is false, which means that the MQL session appears as a button on the Windows task bar for eMatrixMQL/MQLIO, matrix -wizard, matrix -c, mql -c -d, and openedit, but cannot be opened. (Note: use of mql -c without '-d' does display the window). MX_ANNOTATION_TYPE sets the non-English word used for Annotations. A business object type of the name specified here must be defined in order for the Annotation function to operate properly when used in a non-English setting. The default is Annotation.

200

ENOVIA Live Collaboration Installation Guide