Configuring Settings in File-Based Settings Mode

The default settings implementation is based on a runtime environment file. This file specifies a set of ordered references to settings repositories, describing the hierarchical concatenation of the administration. Each repository contains a set of setting files containing in turn the settings parameter values.

Settings repositories can be deployed on server machines through NFS/DFS and/or locally on client machines. The file-based settings mode provides easy deployment on LAN or VPN and good performance, however it is not a satisfactory solution for WAN deployment. Furthermore, this persistency method does not comply with the current storage architecture for the 3DEXPERIENCE platform, whereby all data are stored in the database, and does not benefit from the P&O and security model provided by the database.

This page discusses:

How Settings are Concatenated and Inherited in File-Based Settings Mode

Settings are based on a hierarchical concatenation mechanism.

This means that the company level can lock any parameter value for the departmental level which can lock in turn any parameter value for the end user level. Any parameter that has not been locked by an upper level can be superseded by a lower level. Any number of administration levels is possible.

Default Values in the Software

The 3DEXPERIENCE platform provides default values for all settings. This enables you to start a session without any settings files (for example, if settings have been deleted accidentally). End users can run a session and use the defaults.

Order of Priority

Setting files are stored in directories referenced in the 3DEXPERIENCE platform runtime environment by the CATReferenceSettingPath and CATUserSettingPath environment variables:

  • CATReferenceSettingPath points to the directory (or the concatenation of directories) where administrator settings are stored. The order of the directories represents the adminstration hierachy.
  • CATUserSettingPath points to the directory where user settings are stored.

When a session is started, the directories pointed to by these variables are searched in the following hierarchical order: all files found first in the CATReferenceSettingPath, and then in the CATUserSettingPath will be read in this order.

When a session is started, if no setting file is found either in the CATReferenceSettingPath or in the CATUserSettingPath, the setting value is the default provided by the software.

If settings files have been deleted, an end user will inherit the setting values set by the administrator or the default values provided by the software.

If there are administrator directories pointed to by CATReferenceSettingPath, and the settings have not been locked, the value is the value written in the last administrator's file found in CATReferenceSettingPath, or in the user file found in the CATUserSettingPath. In this case, the end user will still be able to modify the settings.

Concatenation Mechanism Involving One or More Administration Levels

The correct way to administrate the settings is to first of all build a logical view of the administration hierarchy like this:

The top-level is the Company. This level is administrered by administrator CompAdm and contains departments DepX and DepY, administered by administrators DepXAdm and DepYAdm respectively. Projects PrjA and PrjB are associated with DepX, and PrjC with DepY. User1 and User2 work on project PrjA, which is administered by administrator PrjAAdm, User3 works on PrjB which is administered by administrator PrjBAdm, and User 4 works on PrjC which is administered by administrator PrjCAdm.

The next task is to create a runtime environment file mapped to each level. In our example, zoom partially on the overall structure and concentrate on the branch containing DepX and PrjA as illustrated. The box on the right-hand side represents the runtime environment file:



Company-level administrator CompAdm creates a runtime environment file for the company level, and sets CATReferenceSettingPath to point to the directory CompRefDir.

At the department level, administrator DepXAdm creates a runtime environment file for the department level, and sets CATReferenceSettingPath to concatenate two directories, CompRefDir and DepXRefDir in that order.

Finally, project administrator PrjAAdm creates a runtime environment file for the project level then sets CATReferenceSettingPath to concatenate three directories, CompRefDir, DepXRefDir and PrjARefDir in that order.

The key concept here is the role of the runtime environment file. Running a session executes a runtime environment file. When multi-level administration is implemented, an end user inherits the settings located in the directory (or directories) pointed to by the CATReferenceSettingPath variable of the runtime environment being executed.

Concatenating Settings Locks

If there are administrator directories pointed to by CATReferenceSettingPath, and settings have been locked, the setting value is the value written in the first administrator directory where this attribute has been locked. End users will not be able to modify the settings.

For full details about how to start a session in administrator mode for the purpose of locking settings, refer to Locking or Modifying Settings.

For a fully detailed scenario illustrating how settings are concatenated and inherited, and involving multiple administration levels, refer to Detailed Scenario Illustrating Concatenation and Inheritance Mechanisms.

Different users may want to set different types of locks at different levels for a variety of reasons.

If several users set locks in different folders using the same environment, end users of the same environment will inherit all the locks set by those administrators.

To implement this solution, you must concatenate several CATReferenceSettingPath values as illustrated below:



In this example:

  • one administrator (starting in administration mode) locks settings in "Environment 1" at the site level
  • on the same site, two administrators (also starting in administration mode) in two different workshops lock settings in "Environment 2" and "Environment 3" respectively
  • users 1 and 2 run a session with "Environment 2" and inherit the setting locks in "Environment 1" and "Environment 2" respectively
  • users 3 and 4 run a session with "Environment 3" and inherit the setting locks in "Environment 1" and "Environment 3" respectively

Where Are Settings Files Located on Windows?

The location of settings files on Windows platforms is inspired by the general data and settings management requirements operating on the Windows platform, which provides an underlying infrastructure allowing you to separate user data, user settings and computer settings.

The mechanism used is the CSIDL value mechanism. This mechanism allows:

  • your permanent settings (CATSettings) to roam as part of your user profile (CSIDL_APPDATA)
  • your temporary settings (CATTemp, etc.) to be still stored in the user profile, but prevents them from roaming (CSIDL_LOCAL_APPDATA).

The following table will help you determine where your settings are located on Windows:

Environment VariableLocation
CATReferenceSettingPathC:\Program Files\Dassault Systemes\B422\win_b64\startup\Settings
CATUserSettingPath CSIDL_APPDATA\DassaultSystemes\CATSettings\DSKEY_RELEASE_LEVEL\Desktop
CATTemp CSIDL_LOCAL_APPDATA\DassaultSystemes\CATTemp
CATReport CSIDL_LOCAL_APPDATA\DassaultSystemes\CATReport
CATErrorLog CSIDL_LOCAL_APPDATA\DassaultSystemes\CATTemp\error.log

  • C:\Users\user\AppData\Roaming is the default value for the CSIDL_APPDATA.
  • C:\Users\user\AppData\Local is the default value for the CSIDL_LOCAL_APPDATA.
  • 422 is the DSKEY_RELEASE_LEVEL.