This document explains those environment variables.
The environment variables are not listed in any particular order here.
This document explains many undocumented environment variables. Therefore, customers are advised not to use these environment variables unless instructed by Informatica Global Customer Support.
R&D may disable any undocumented features turned on by a special environment variable at any point.
The value of SSATOP is the root installation directory of IR software.
Deprecated since Informatica 9.1 (replace with SSATOP)
= $SSATOP/bin – the location of the IR Software executables (programs and scripts) shipped with IR. With the exception of some configuration files such as odbc.ini IR Software never writes anything to this location (at runtime) and neither should the customer.
This is the location where IR software creates most new files, many of which are temporary working and log files.
This can be used to place the server logs in a certain directory. If not set, the value of SSAWORKDIR is used instead.
= $SSATOP/ids – the default working directory, under which IR software expects to find some files related to the initial installation testing. This variable was introduced as a workaround for a known problem and may be removed in the future.
= $SSATOP/pr – the root directory under which the SSA-NAME3 system directories are placed. The SSA-NAME3 populations are then placed into these system directories.
Location for temporary files, such as installation and other log files, and ephemeral sort work files. We recommend that is set to each user separately, for instance, to $HOME/tmp.
If none of the log location redirection variables is set, then all debug log files (.dbg) will be written to SSATEMP by default. This behavior can be used to override the use of SSATEMP in such a case.
The host addresses of various IR Product servers are specified using SSA_xxHOST and SSA_xxPORT variables where xx is a different string for each server process. Some of these are mandatory and some optional.
These variables are used internally and in most cases only at build time for recognizing the current product version. Not all of these even are or need to be set in runtime environment. The ones that are set should not be changed at runtime.
The value of SSA_ARCH identifies the current platform (architecture) to the IR Software. This value should not be changed.
This contains the name of the platform specific “null” file, which is /dev/null on UNIX and NULL on Windows. This value should not be changed.
This variable contains the directory separator string (‘/’ on UNIX and ‘\’ on Windows). This value should not be changed.
This contains the fully-qualified path to the Java (JDK or JRE) executable that IR Client (GUI) Software uses.
This contains the fully-qualified path to the Internet browser executable that IR Client (GUI) Software uses.
This contains the name of the log file that the initial installation test uses.
This variable informs MDM-RE to output UTF-16 encoded Unicode into ’W’ columns when converting data extracted from XML documents produced by Siebel. When set to zero, it uses UTF-8. The default (when not specified) is UTF-16.
This variable specifies the size of the XML parsing buffer (in bytes) of the XS Server. This should be at least as large as IDS_PAGE_SIZE * <max bytes per Siebel Msg>. The former is a Profile Attribute of the ISSLaunchBuildLoadFile workflow and the latter is a function of the size and number of fields included in the IO.
This variable specifies the connection string for the Database.
This variable specifies the connection string for the Rulebase containing the IIR System(s).
Contains the abbreviation of the underlying DBMS type. This is one of the following: ora, udb, msq, myq or syb. Could also be sdb in DCE.
(Set internally as required) The database access interface. This is either odb or sdb.
If SSA_SERVER_STATS=YES and SSA_RBNAME is set, then you can view Server process progress information in the Console Client. As this has the potential to impact performance, it is not switched on by default.
Fully qualified name of the DBMS specific load utility. Usually sqlldr (Oracle), db2 (UDB), bcp (MSQ and SYB) or myqldr (MYQ).
Contains a colon-separated list of environment variables that cannot be set by the console client. This list contains the following variables by default: SSADEBUG and SSA_RESTRICTED_VARS.
All IIR/MDM-RE Windows batch and UNIX shell scripts as well as some programs produce more verbose output for debugging purposes when SSADEBUG is set to any value. If the value is “all” (in lower-case), then the Windows batch scripts turn on echo and subsequently show all commands that the script executes.
Table Loader automatically creates n key generation threads, where n is the number of CPUs available. You may override this value by setting the environment variable SSALDR_KEYTH=n.
Table Loader automatically creates n loader threads, where n is the number of CPUs available. You may override this value by setting the environment variable SSALDR_LOADTH=n.
In general, the DBMS load is an I/O intensive operation. Creating too many Loader threads may cause I/O contention that could slow down the load process.
All loader threads cannot be used in some cases, which are as follows:
The buffer size of input reader thread of the table loader, where the value is number of records. The default is 5000. This parameter is also used to calculate the size of the key generation output queues. They are calculated as:
SSALDR_RBSIZE / number_of_key_threads * 8
These variables control the memory usage of some programs included in IR Software. Usually, change only if there is a limited amount of memory available or if requested by R&D.
When a foreign language version of Oracle is used, two environment variables must be defined to specify the foreign language text that corresponds to the English strings that the table Loader is looking for. Set the environment variables SSALDR_ORA_READ_TXT and SSALDR_ORA_REJECT_TXT to the foreign language strings that correspond to "Total logical records read:" and "Total logical records rejected:" messages respectively. These variables must be the complete string, up to and including the terminating colon, starting from the left margin of the output.
The MSQ, SYB and MYQ implementation of the Table Loader searches for the phrase "rows copied." as this precedes the number of rows loaded into the table. When using a non-English locale, you may provide alternate text for this phase using the environment variable SSALDR_MSQ_COPIED_TEXT for MS SQL Server and Sybase or SSALDR_MYQ_COPIED_TEXT for MySQL Server.
This contains a string that controls various, mainly debugging-related options for IR Software. A ‘+’ preceding an option means that the feature in question is turned on and ‘-‘ turns it off. The supported options are:
c trace count
C log time options
d dump stack on error
f xalloc check freed areas (very slow, much mem)
F xalloc flood freed memory (very light)
g xalloc full guard check (very slow)
G xalloc light guard check
i trace time
l trace log all calls (very verbose)
L log bad RCs (ie. errors) to .dbg file. We recommend that this is always on.
m fast strx checks
M log time options
p xalloc progress
P xalloc pointer check
q dump XML messages
r log all search records
s xalloc guard checks (slow)
S xalloc extensive guard checks (very slow)
T trace all searches (server debug log)
u show resource usage
U show file io stats
x xalloc alloc/free checks
X xalloc size histogram
z zap malloc memory
Z zap calloc memory
These options are case-sensitive.
Some of these values will cause significant performance degradation and hence should not be set in a production environment.
The above list contains some values that are not included in user documentation. These should be set in customer environment only on request by R&D for some special – short-time – debugging.
The ones shown in bold in the preceding list are the most likely options to be used in user environment.
These two variables control the timing of the periodical housekeeping tasks that the Real Time Synchronization Server performs. When something is sent for real time syncing, it is placed on a queue. When processing is complete, the responses are placed on another queue, from which they can be retrieved, for instance, by the calling application. After a period of time on the queue, the responses are thrown away. It may well be that the requestor is not interested in a response. Or, it errors off.
SSA_SYNC_HEARTBEAT defines how often the housekeeping is performed. It can cause processing to halt while it does its work. Therefore, we made it configurable. The default value is 1 minute.
SSA_SYNC_TIMEOUT defines how long a response remains on the queue before it is discarded. We made this configurable as well. The default value is 10 minutes.
All database access by IR Software is configurable in a file called odbc.ini. When opening this file, the IR Software first checks if the environment variable ODBCINI is set and if yes, then the software checks if a file called odbc.ini is in the directory pointed to by the value of ODBCINI. If not, the software performs the same check using the environment variable HOME and if still unsuccessful, then in the final step the same check is performed using SSABIN.
If a database dictionary file dbdict.dic is used, then the IR software will first look for this file in a directory pointed to by the environment variable SSA_DBDICT. If the variable is not set, the dictionary file is expected to be in SSABIN.
When IR Software attempts to open some other configuration files (usually .ini; such as HTTP Search Server configuration file htserv.ini, XML Search Service configuration file xmserv.ini, NSA-Batch Service configuration file xsserv.ini, Real-Time Synchronization Service configuration file xrserv.ini or xrserv.xml and possibly others that we may add in the future), the file is first searched in SSAINI, followed by HOME and finally defaulting to SSABIN.
Used to set the database schema if different than the user name.
This environment variable can be set to overwrite the default or SDF-defined number of threads when running the DCE Clustering or static clustering in IIR.
When not using full key data, there is a window for a temporary integrity problem, where an IDT record cannot be found by a search. We have added a retry mechanism to the search function to address this problem. The environment variable SSA_APIC_INTEGRITY_RETRY can be used to control the number of retries allowed. The default number of retries is 10.
The sole purpose of this undocumented environment variable is to keep the temporary project directory (and files in it) when running the IR static clustering. Set this variable to YES to enable this functionality.
Contains the name of the awk program used by some of the scripts that we supply.
Contains the name of the grep program used by some of the scripts that we supply.
The root directory of Java (jdk or jre) installation.
= $JAVA_HOME/bin (or %JAVA_HOME%\bin)
Points to the location of the javahelp class container jhall.jar. By default, this is same as SSABIN.
Behavior of some DBMSs change depending on the setting of NLS_LANG. IR Software honors this setting and behaves accordingly.
If the value of this variable is a valid filename, the Microsoft ODBC driver writes its own trace information to that file.
This variable is undocumented.
If this variable is set to any value and the DBMS being used is Oracle, then the software issues the following SQL command.
ALTER SESSION SET SQL_TRACE=TRUE
Trace output is written to the UDUMP directory of the database. The default name for a trace file is INSTANCE_PID_ora.trc where:
· INSTANCE is the name of the Oracle instance, and
· PID is the operating system process
Trace output is quite unreadable. However, Oracle provides a utility, called TKProf, that can be used to format trace output.
The value of this variable is the location of Sybase defncopy utility. We use it to extract the trigger code into a file.
If the computer crashes (and all processes terminate), the Rulebase remains locked. The next time a new pair of parent/child Rulebase Servers are started, the parent generates a new unique Id. It will not match the Id stored in the Rulebase, so the child server will fail to start. In this situation, you can manually override the lock by setting an environment variable to the same Id that currently locks the Rulebase. For instance,
When the Rulebase server is started, it will use the environment variable to unlock the Rulebase (as long as the two Ids match). It will then use the freshly generated parent Id to re-lock it. Therefore, the environment variable can only be used once to unlock the database.
A manual restart is usually required after a power outage or reboot. When SSA_RB_RESTART_ID is set to 0, IIR/MDM-RE will automatically attempt to detect if the original process that locked the Rulebase is still running. If it is not, the restart will be automatic (with no intervention required).
When SSA_RB_RESTART_ID is set to 0, it is possible to inadvertently start multiple Rulebase servers. If this occurs, Rulebase corruption will result. We strongly recommend that SSA_RB_RESTART_ID is not left in any start-up script or in the environment after a server restart.
The UDDI configuration file. If this is provided, its contents will take priority over the other SSA_UDDI environment variables.
The UDDI Business Name. The name of the party publishing the service, which is you.
The userid to log on to UDDI with.
The password for logging on to the UDDI publisher.
The UDDI inquiry URL, which is probably something like:
The UDDI publisher URL, which is probably something like
Our OEM software vendors set this variable to bypass the License Server.
If a customer is using SSA-Name3 extensions to allow them to use IIR or DCE in a way that is compatible with SSA-Name3 v1, then SSAUSGDIR should be set to point to the location of SSA-NAME3 v1 Service Group and SSAUSGNAME should contain its name.
IR Software (both executables and scripts) sets various variables as needed. For instance, to share information between the Server and the processes it launches.
There are some undocumented environment variables that are not listed above. For instance, there may be some customized feature that can be enabled by setting an environment variable. One such example is the variable SSALDR_KEEP_TRIG that was recently added for the benefit of one customer to disable the default behavior of deleting table triggers when the IDT is reloaded.
Other examples include variables that can be set to retain old behavior when the default has changed or variables that can be set to enable a workaround for a known issue in some third party software. R&D will advise Customer Support whenever such an environment variable needs to be set.
What can we do to improve this information (2000 or fewer characters)