Installing the Vault Server Manually

This task will show you how to install manually a vault server on UNIX. 

On Windows, we recommend that you install a vault server using the interactive tools provided.

Data Structure Creation

Beware: Each Vault Server is supposed to have its own data structure. Do not share Vault Server data structure between several Vault Server!

You will find the reference files for the data structure creation (tables, index, etc.) under the following directory:


The $OSDS value could be aix_a, hpux_b or solaris_a depending on your operating system.

The suffix of these reference files is .clp for DB2 and .sql for Oracle.

They are named:

VPM_VAULTFILE.clp and VPM_VAULTFILE.sql when creating tables 

grant_VPM_VAULTFILE.clp and grant_VPM_VAULTFILE.sql when creating grants on tables 

You can also use the and the files to remove respectively tables and grants on tables.

When creating your data structure, you have to customize the above-mentioned files.

To do so:

1. Duplicate the following files and rename them as indicated below:

     Original file name:                Duplicated file name:                                                   

2. Change the name of the structure owner (the default owner is VPMADM) and the tablespaces name if necessary. In the case of the grant file, we advise you to change the "to public" right into "to vault_structure_owner".

3. Execute the file and the related grant file ( on your database:

a. Logon to the database as Database Administrator

For DB2:

b. Under the DB2 prompt, run the command:
  db2 -tvf file_fullpathname.clp

For Oracle:

b. Under sqlplus, run the command:
 start file_fullpathname.sql

Register the New Vault Server on the Orbix daemon

1. Execute the following command:

IT_CONFIG_PATH= install_dir/startup/orbix

Run it using catstart, or export the environment before like this:

catstart -env -direnv -run "/bin/ksh"

Putit -h machine_name -shared VaultServerName "install_dir/code/command/catstart -env \"env_name\" -direnv \"env_dir" -run install_dir/code/command/runENOVVaultStarter -object \" MyVaultOwner_UID MyVaultOwner_GID env_name env_dir\ ""

chmodit VaultServerName i+all
chmodit VaultServerName l+all

The values for the parameters are:

VaultServerName: name of the CORBA service for the VaultServer.

Beware:'_' are not allowed in the Vault server name and the Vault server alias name!

MyVaultOwner_UID: UNIX user id of the vault administrator user.
MyVaultOwner_GID: UNIX group id of the vault administrator user.
IT_CONFIG_PATH: path of the iona.cfg file under the installation. On a standard installation, this file is under startup/orbix directory.


With the values below:

Install_dir: /usr/DassaultSystemes/B18/solaris_a
Machine: reverdsy
VaultServerName: ENOVIAVaultServer
Env_name: ENOVIA_V5_VPM.V5R18.B18
Env_dir: /CATEnv
MyVaultOwner_UID: 1400
MyVaultOwner_GID: 360

We get:

IT_CONFIG_PATH= /usr/DassaultSystemes/B18/solaris_a/startup/orbix

Putit -h reverdsy -shared ENOVIAVaultServer "/usr/DassaultSystemes/B18/solaris_a/startup/orbix/code/command/catstart -env \"ENOVIA_V5_VPM.V5R18.B18\" -direnv \"/CATEnv" -run /usr/DassaultSystemes/B18/solaris_a/startup/orbix/code/command/runENOVVaultStarter -object \"1400 360 ENOVIA_V5_VPM.V5R18.B18 /CATEnv\""

chmodit ENOVIAVaultServer i+all
chmodit ENOVIAVaultServer l+all


If all is OK, you should have a ENOVIAVaultServer.imp file under the following directory:


Then you have created the Orbix service name ENOVIAVaultServer.


The above command will generate a file named ENOVaultServer.imp in the directory:


The file ENOVaultServer.imp looks like this:

Name              : ENOVaultServer 
Comms            : cdr/tcp 
Activation        : shared 
Owner             : root
Launch            : ;all;
Invoke            : ;all;
ImpRep Version    : 2
no. of servers    : 1
server's port     : 0

Marker Launch Command * /home/DS/B18/solaris_a/code/command/runENOVVaultStarter 1415 363

Vault Settings Creation

The new Vault Setting software is based on an extended JAVA properties mechanism. So the Vault Setting file looks like a java property file. When the Vault tries to get a property, the search order is:

1. in system properties (java only: "-D" option in launch command line)

2. in environment (shell variables)

3. in vault properties file.

There are two kinds of Vault settings: server and client.

Vault Server Settings

Each Vault Server is supposed to have its own Vault Server properties file. Do not mix properties of two Vault Server in the same properties file. It is not supported!

The default location of the Vault server settings file is:


The default filename is no longer, but:

VaultServer setting purpose

VaultServer settings are used to manage:

Here are keys used by a VaultServer:

Mandatory Keys

VaultServer_Name                   : vault server Orbix service name
VaultServer_HostName             : vault server host name
VaultServer_DaemonPort          : Orbix daemon listen port
VaultServer_TimeOut               : vault server timeout (unit: milli second)
VaultServer_ThreadNumber       : number of thread waiting for client request
VaultServer_DBMINPoolSize       :  minimum number of connections for the vault server database connection pool
VaultServer_DBMAXPoolSize      : maximum number of connections for the vault server database connection pool
VaultServer_TimeZoneRawOffset  : time zone offset (unit: milli second), used for document creation
                                  and modification date
VaultServer_DBName              : name of the database where vault tables are
VaultServer_DBVendor            : database vendor pertaining to the database name above
VaultServer_DBUser                :  database connection user
VaultServer_DBSchema           : database structures owner
VaultServer_DBPassword         : database connection user password

For detailed information about how to generate the password, refer to the description of the GenVaultPassword command in Database password encryption for the Vault Server properties file.

VaultServer_NumOfRepo          : number of Vault Server repositories
VaultServer_Repo_x_Name       : name of the Vault Server repository
VaultServer_Repo_x_Path        : path of the Vault Server repository

For more information, refer to Multiple File System Support.


Beware: the following keys are no longer valid since release V5R8:

VaultServer_Default_Secured_StorageLocation   : default vault secured path for files
VaultServer_Default_Tmp_StorageLocation       : default vault temporary path for files

Those keys are still allowed but they can't be mixed with the keys replacing them (VaultServer_NumOfRepo, ), it is not supported!

Optional Keys

Standard optional Keys:

VaultServer_TmpFilesAccessRights          :  file access rights under temporary path (default: 600)
VaultServer_SecuredFilesAccessRights     : file access rights under secured path (default: 400)
VaultServer_LogRemovedFiles                  : trigger logging of delete operations (default: false)
VaultServer_RemoveFiles                        : trigger file delete on disk (default: true)
VaultServer_IsDBPasswordEncrypted        : trigger password encryption use (default: true)
VaultServer_DBURL                              :  JDBC connection string
VaultServer_DBDriver                           : JDBC driver class to load
VaultServer_DBTransIsoLevel                  : database transaction isolation level
VaultServer_FDSMIN                             : free disk space threshold
VaultServer_Repo_x_ReadOnly                 : trigger read only mode on a Repo (default: false)
VaultServer_Repo_x_Priority                    :  modifies use frequency (unit: double, default: 1.0)
VaultServer_Repo_x_NumOfSecDir            :  number of secured directories for the repository number x                                                   (default: 1)
VaultServer_Repo_x_TmpDirName                  :  name of the tmp directory for the repository number x (default:                                                   tmp)
VaultServer_Repo_x_SecDirName_y          : name of the secured directory for the repository number x                                                   (default: securedy)
VaultServer_ENOVIStorageLocation_Implementation: class to load for storage location user exit
VaultServer_ENOVIDocIndexation_Implementation  : class to load for document indexation user exit
VaultServer_MilliSecondTimestamp               :  trigger timestamp millisecond precision (default: true on DB2 and false on ORACLE)
VaultServer_ReadOnly :           trigger read only mode on the whole vault
VaultServer_Trace                              : trigger trace (default: OFF)
VaultServer_LicenseName                     : forces the use of a particular license (instead of VAR); this license must be an authorized       license for the VSA product

Optional Keys for DB2 DATALINK

VaultServer_DB2DATALINK                :  trigger datalink mode (default: false)
VaultServer_DLFMHostServerName         : datalink file manager host server name (only for datalink mode)

Optional Keys for a Cache VaultServer

VaultServer_Cache                      : trigger cache mode (default: false)
VaultServer_Cache_MaxSize              : Maximum size of Vault Cache (unit: kb)
VaultServer_Cache_CleanThreshold       : threshold for cleaning file (percent of cache max size)
VaultServer_Cache_CleanRate            : targeted size after cleaning (percent of cache max size)
VaultServer_Cache_CleanEnabled         : trigger cleaning mode on (default: true)
VaultServer_Cache_TimeoutForClean      : time between two cleaning (unit: milli second)

Standard VaultServer properties file example

## Vault Server Properties File
## Orbix parameters

VaultServer_Name                = ENOVIAVaultServerOrbSrv
VaultServer_HostName            = regis
VaultServer_DaemonPort          = 1572
VaultServer_TimeOut             = 36000000

## Request execution parameters
VaultServer_ThreadNumber        = 2
VaultServer_TimeZoneRawOffset   = 3600000

## Database connection pool parameters
VaultServer_DBMINPoolSize       = 4
VaultServer_DBMAXPoolSize       = 6

## Database connection parameters
VaultServer_DBName              = AIXINT8
VaultServer_DBVendor            = oracle
VaultServer_DBUser              = tacr
VaultServer_DBPassword          = ******

## VaultServer file repositories parameters

VaultServer_NumOfRepo           = 2
VaultServer_Repo_0_Name         = Repo0
VaultServer_Repo_0_Path         = /VAULTCXR8/Repo0
VaultServer_Repo_0_NumOfSecDir  = 2
VaultServer_Repo_0_TmpDirName   = TmpDirectory
VaultServer_Repo_0_SecDirName_0 = SecuredDirectory0
VaultServer_Repo_0_SecDirName_1 = SecuredDirectory1
VaultServer_Repo_1_Name         = Repo1
VaultServer_Repo_1_Path         = /VAULTCXR8/Repo1

## Trace parameter
VaultServer_Trace               = OFF

 Explanation of Example

This properties file is corresponding to a standard VaultServer (no DATALINK or VaultCache) running on a workstation named "regis". The Orbix service name, which is the name declared is registered on the Orbix daemon, is ENOVIAVaultServerOrbSrv. The Orbix daemon is listening on port 1572 on this workstation. The VaultServer timeout is exactly ten hours. Two request execution threads and four database connections are created at start time. The server time zone is GMT+1. The database used is an Oracle database named AIXINT8 and the connection user is tacr. Two Vault repositories are declared.

Vault Client Settings

Several Vault Clients can use the same Vault Client properties file.

VaultClient setting purpose

VaultClient settings are used for:

VaultAliasName concept:

The VaultAliasName is the way for VaultClient applications to identify a VaultServer. A VaultClient application needs three data to connect a VaultServer. It needs VaultServer Orbix service name, Orbix listen port on the remote workstation where VaultServer is running and the remote workstation name. VaultClient properties file is used to link a given VaultAliasName to the three data identifying a given VaultServer.

Here are the keys used by a VaultClient:

Mandatory Keys

VaultClient_DefaultAliasName      : default vault alias name
VaultClient_ReadProtocol          : number of allowed read protocol
VaultClient_ReadProtocol_0     : first read protocol
VaultClient_ReadProtocol_1     : second read protocol
VaultClient_WriteProtocol         : number of allowed write protocol
VaultClient_WriteProtocol_0     : first write protocol
VaultClient_BlockSize             : size in bytes of block for read and write operation

Optional Keys

VaultClient_Active_ReadProtocol   : file transfer protocol to use for read operation
VaultClient_Active_WriteProtocol  : file transfer protocol to use for write operation
VaultClient_ReadOnly : trigger read only mode (default: false)
VaultClient_Trace                 : traces activation (java only, default: OFF)

How to catalog a new VaultServer

In order to do that, you have to declare a new VaultAliasName pertaining to the VaultServer you want to catalog. As read and write operations are separate, you have to add six data by VaultAliasName which are: 

VaultClient_MyVaultAliasName_ReadVaultServerName        : 
Orbix service name of the target vault server for read operation

VaultClient_MyVaultAliasName_ReadVaultServerHostName    : 
Host name of the target vault server for read operation

VaultClient_MyVaultAliasName_ReadVaultServerDaemonPort  : 
Orbix listen port of the target vault server for read operation

VaultClient_MyVaultAliasName_WriteVaultServerName       : 
Orbix service name of the target vault server for write operation

VaultClient_MyVaultAliasName_WriteVaultServerHostName   : 
Host name of the target vault server for write operation

VaultClient_MyVaultAliasName_WriteVaultServerDaemonPort : 
Orbix listen port of the target vault server for write operation

These keys are mandatory for the default alias name.

You can catalog as many VaultServers as you want in a VaultClient properties file. But do not declare a VaultAliasName twice. Only the first entry will be taken into account.


VaultClient properties file example:


## Vault Client Properties File
VaultClient_DefaultAliasName                   = Vault1

VaultClient_ReadProtocol                       = 2
VaultClient_ReadProtocol_0                     = CORBA
VaultClient_ReadProtocol_1                     = NFS

VaultClient_WriteProtocol                      = 2
VaultClient_WriteProtocol_0                    = CORBA
VaultClient_WriteProtocol_0                    = NFS

VaultClient_BlockSize                          = 262144

VaultClient_Trace                              = OFF

## Vault1 alias entry
VaultClient_Vault1_ReadVaultServerName            = Vault1OrbSrv
VaultClient_Vault1_ReadVaultServerHostName      = laureen
VaultClient_Vault1_ReadVaultServerDaemonPort   = 1570

VaultClient_Vault1_WriteVaultServerName           = Vault1OrbSrv
VaultClient_Vault1_WriteVaultServerHostName     = laureen
VaultClient_Vault1_WriteVaultServerDaemonPort  = 1570

## Vault2 alias entry
VaultClient_Vault2_ReadVaultServerName            = Vault2OrbSrv
VaultClient_Vault2_ReadVaultServerHostName      = floydsy
VaultClient_Vault2_ReadVaultServerDaemonPort   = 1572

VaultClient_Vault2_WriteVaultServerName           = Vault2OrbSrv
VaultClient_Vault2_WriteVaultServerHostName     = floydsy
VaultClient_Vault2_WriteVaultServerDaemonPort  = 1572

## Vault3 alias entry
VaultClient_Vault3_ReadVaultServerName            = Vault3OrbSrv
VaultClient_Vault3_ReadVaultServerHostName      = bayeux
VaultClient_Vault3_ReadVaultServerDaemonPort   = 1576

VaultClient_Vault3_WriteVaultServerName           = Vault3OrbSrv
VaultClient_Vault3_WriteVaultServerHostName     = bayeux
VaultClient_Vault3_WriteVaultServerDaemonPort   = 1576

Explanation of Example

This VaultClient properties file declares three VaultAliasName that are Vault1, Vault2 and Vault3. The VaultServer Vault1OrbSrv Orbix service name is associated to the Vault1 alias name. This VaultServer is running on a workstation named laureen and the Orbix daemon listen port is 1570. The VaultServer Vault2OrbSrv Orbix service name is associated to the Vault2 alias name. The VaultServer Vault3OrbSrv Orbix service name is associated to the Vault3 alias name.

Properties file access path:

The vault application default access path for properties file is: 


You can change this behavior by exporting the keys below in your environment:

VaultServer_PropertiesFilePath    :     Path of the vault server properties file
VaultServer_PropertiesFileName    :     Name of the vault server properties file
VaultClient_PropertiesFilePath    :     Path of the vault client properties file
VaultClient_PropertiesFileName    :     Name of the vault client properties file

For instance:

export VaultServer_PropertiesFilePath
export VaultServer_PropertiesFileName
export VaultClient_PropertiesFilePath
export VaultClient_PropertiesFileName

Beware: '_' are not allowed in Vault server name and Vault server alias name!

Multiple File System Support

In order to allow declaration of tmp and secured directories on several file systems, the concept of Vault Server Repository has been introduced. A Vault Server Repository is defined by a name, a tmp directory and a set of secured directories. These directories have to be on the same file system for a given Vault Server Repository. It is necessary to improve performances and reliability. The following Vault Server properties have been added to support this new feature.

Vault Server Repository Definition Keys

Mandatory Keys

Number of Vault Server Repositories: VaultServer_NumOfRepo.

For instance, the line:

VaultServer_NumOfRepo = 2

means that two Vault Server Repositories are defined below.

Repository name: VaultServer_Repo_x_Name

(x stands for the repository index rank. It begins at 0)

For instance, the line:

VaultServer_Repo_0_Name = Repo0 

means that the name of the Vault Server Repository number 0 is Repo0.

Repository path: VaultServer_Repo_x_Path

(x stands for the repository index rank. It begins at 0)

This property defines the root path under which tmp and secured directories are supposed to be created. 

For instance:

VaultServer_Repo_0_Path = /VAULTCXR8/Repo0 

means that tmp and secured directories are created under the directory /VAULTCXR8/Repo0

Optional Keys

Minimum free disk space threshold (unit: kb): VaultServer_FDSMIN.

For instance, the line:

VaultServer_FDSMIN = 1000 

means that the Vault Server will not use  a file system any more if there is less than 1000 free kb on it. Default value for this property is: 0.

Tmp directory name: VaultServer_Repo_x_TmpDirName

(x stands for the repository index rank. It begins at 0)

For instance, the line:

VaultServer_Repo_0_TmpDirName = tmpDir0 

means that the tmp directory for Vault Server repository named Repo0 is /VAULTCXR8/Repo0/tmpDir0. The default value for this property is: tmp.

Number of secured directories definition key: VaultServer_Repo_x_NumOfSecDir

(x stands for the repository index rank. It begins at 0)

For instance the line:

VaultServer_Repo_0_NumOfSecDir = 2

means that two secured directories are defined below. The default value for this property is: 1.

Secured directory name: VaultServer_Repo_x_SecDirName_y

(x stands for the repository index rank. It begins at 0; y stands for the secured directory index rank. It begins at 0)

For instance, the line:

VaultServer_Repo_0_SecDirName_0 = secDir0

means the the first secured directory for Vault Server Repository named Repo0 is /VAULTCXR8/Repo0/secDir0. The default value for this property is: securedy (where y stands for the secured directory index rank. It begins at 0)

Read only feature: VaultServer_Repo_x_ReadOnly

(x stands for the repository index rank. It begins at 0)

For instance, the line:

VaultServer_Repo_0_ReadOnly = true

means that the Vault Server repository named Repo0 is read only. The default value for this property is: false.

Priority feature: VaultServer_Repo_x_Priority

(x stands for the repository index rank. It begins at 0)

For instance, the line:

VaultServer_Repo_0_Priority = 2.0

means that the Vault Server repository named Repo0 is two-time more used than it would be by default when creating new documents. The default value for this property is: 1.0.


Vault Server properties file example

# Vault Server Repositories

# Number of Vault Server Repositories

VaultServer_NumOfRepo = 3

# First Vault Server Repo

VaultServer_Repo_0_Name = Repo0

VaultServer_Repo_0_Path = /VAULTCXR8/DirOfRepo0

VaultServer_Repo_0_TmpDirName = TmpDirOfRepo0

VaultServer_Repo_0_NumOfSecDir = 2

VaultServer_Repo_0_SecDirName_0 = SecDir0OfRepo0

VaultServer_Repo_0_SecDirName_1 = SecDir1OfRepo0

# Second Vault Server Repo

VaultServer_Repo_1_Name = Repo1

VaultServer_Repo_1_Path = /VAULTCXR8/DirOfRepo1

VaultServer_Repo_1_NumOfSecDir = 3

# Third Vault Server Repo

VaultServer_Repo_2_Name = Repo2

VaultServer_Repo_2_Path = /VAULTCXR8/DirOfRepo2

The lines above mean that the following directories are supposed to be created for Repo0, Repo1 and Repo2:













File dispatching rules

A user exit mechanism (ENOVIStorageLocation interface) is used to know where to write new or modified files into Vault repository directories. If you want to code your own user exit, keep in mind that the code has to be thread safe.

The default user exit implementation we supply dispatch files depending on free disk space on file system. The more free disk space you have on a file system, the more you will have new or modified files written on it.

The file dispatching rule is not verified with one single file but it is a statistic rule. For example, there are two vault repositories (REPO1 and REPO2) such that REPO2 free disk is space equal to 2 times REPO1 then the file distribution will be such that 1/3rd of files will go in REPO1 and 2/3rd will go in REPO2.

So If you have 3000 files you will have 1000 files in REPO1 and 2000 in REPO2. Of course this rule can not verified if you have only 1 file.

On a given Vault repository, there is no preference between secured directories. The free disk space is not computed per secured directory but it is calculated per Vault repository. So if there are 1000 files in a Vault Repo with 10 secured directories (all created at Vault repository creation time) then you will have 100 files stored per secured directory.

Creating Storage Directories

Creation of secured and tmp directory for VaultServer.

For each defined Vault Server repository create tmp and secured directories:

  1. Log on as VaultOwner OS user.
  2. mkdir    -p      directory_to_create
  3. chmod +rw just_created_directory

Setting Up Your Environment

CLASSPATH issue on vault client and vault server side: the Vault client and server software component are based on JNI operations for file access rights management. So, make sure the JNIVAULT.jar file is in your CLASSPATH.

DB2 mandatory environment variables for JDBC use (vault server side only):

DB2INSTANCE has to be set. For instance: 


CLASSPATH issue on vault server side for JDBC use: add  db2client_home_directory/sqllib/java/ to your CLASSPATH (see db2profile shell in the DB2 client installation to set the value of this variable properly).

LIBPATH (or LD_LIBRARY_PATH ...) issue on vault server side for JDBC use: db2client_home_directory/sqllib/lib has to be in LIBPATH (see db2profile shell in the DB2 client installation to set the value of this variable properly).

ORACLE mandatory environment variables for JDBC use (vault server side only)

NLS_LANG has to be set (US7ASCII, WE8DEC, WE8ISO8859P1, UTF8, ...). This variable is set by default by the Oracle installation. So, you can just keep the default value. For instance:

export NLS_LANG

ORACLE_HOME has to be set. For instance:


TNS_ADMIN has to be set. For instance:

export TNS_ADMIN

CLASSPATH issue on vault server side for JDBC use:


Add $ORACLE_HOME/jdbc/lib/ and $ORACLE_HOME/jdbc/lib/ to your CLASSPATH

Windows XP: 

Add [ORACLE_HOME]\jdbc\lib\ and [ORACLE_HOME]\jdbc\lib\ to your CLASSPATH. 

Set THREAD_FLAG variable to native value: THREAD_FLAG=native

LIBPATH (or LD_LIBRARY_PATH ...) issue on vault server side for JDBC use:


$ORACLE_HOME/lib:$ORACLE_HOME/jdbc/lib has to be in LIBPATH.

Windows XP:

Add [ORACLE_HOME]\lib:[ORACLE_HOME]\jdbc\lib to your PATH.

Dealing with OS limit parameters

The communications between the Vault Client and Vault Server are using TCP/IP sockets. Each socket represents a file descriptor on the Vault Server process. If the file descriptor limit per process is set too low, attempts to open socket connections may be unsuccessful. To resolve this condition, increase the file descriptor limit for the user from which the Orbixd process is started (normally root). Edit the .profile for the user, and add the following:

ulimit -n 1024

Depending on the number of connections needed, this number may need to be increased more. For this change to take effect, you do not have to reboot. Just logoff and then logon again.


To change the hard upper limit of the number of file descriptors in the kernel (which defaults to 1024 per CPU), you can, edit the /etc/system config file to include a couple of entries:

set rlim_fd_max=4096
set rlim_FD_cur=1024

After you change this file, you must reboot for the changes to take effect.


HP-UX kernel parameter configuration for Java support


The default values for HP-UX 11.0 are set too low for VaultServer application. Two kernel parameters need to be set so that the limit of the maximum number of threads per process is not encountered. Usually you will see this problem as a Java Out of Memory error. You will want to set the value of the max_thread_proc higher than the expected maximum number of simultaneously active threads for your application

The maximum number of threads allowed in each process. The minimum value (and default) is 64, often too low for VaultServer application. The maximum value is the value of nkthread.

The total number of kernel threads available in the system. This parameter is similar to the nproc tunable except that it defines the limit for the total number of kernel threads able to run simultaneously in the system. The value must be greater than nproc. The default is approximately twice that of nproc. The maximum is 30000.The suggested value of nkthread is 2*max_thread_proc. If you have many Java processes running and each running process uses many threads, you will want to increase this value.

open files

Problems occur when the value of kernel parameters are set too low for the number of files allowed to be simultaneously open in a process. Be certain that your kernel is configured so that you do not reach the limit for the number of open files for your process. Java opens many files in order to read in the classes required to run your application. A file descriptor is also used for each socket that is opened.

Maximum number of open files.
This value is usually determined by the formula:
NPROC is usually: ((MAXUSERS*5)+64)
For a MAXUSERS of 400, this works out to 5128. You can usually set it higher.

Soft file limit per process

Hard file limit per process
2048 is the maximum value you can set through SAM for maxfiles and maxfiles_lim. Note that you can set the parameters higher by configuring the kernel using the configuration file and then rebuilding the kernel (or by modifying stand/system and doing a mk kernel). Since setting these parameters too low results typically in application failure, you may want to calculate the number you need and then double it. You might also consider inode along with these parameters, that is as a member of the "set". If there's no space in the appropriate inode table then you cannot open a new file.

If the number of pending timeouts on the system exceeds the maximum number of allowable pending timeouts on the system then the system will crash. This undesireable behavior can be avoided by increasing the following kernel parameter:

Maximum number of pending timeouts

If you are opening many sockets, many of which are waiting on I/O, you will likely run into this limit.

Set ncallout to a value greater than the sum of:

nkthread + the number of I/O devices connected to the machine

A callout structure is used by each thread that sleeps waiting for a time-based event. Traditionally the callout structure used by a thread is taken from a pool the size of which is controlled by ncallout. Each thread has a set of timers associated with it, e.g. for nanosleep or sleeping in select(). There are a set of BringYourOwnCallout functions that don't allocate from the pool. The maximum number of callout structures needs to be approximately the maximum number of threads.

Interactively setting user limits

If you suspect that you are running out of file descriptors, you can check your limits by switching to the Bourne Shell and resetting the limits. Simply type in the following:

>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4290772993
nofiles(descriptors) 200

Use the first character to reset any of the values. For example, to increase the number of file descriptors, simply type:

>ulimit -n 5000
>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4290772993
nofiles(descriptors) 5000

Try re-running your application. (Do not exit the shell in which you've just reset your limits.)

Specific use case

Important warning for the installation of a vault running on an AIX server and a local DB2 database

You have to implement a client/server database connection for the vault, because of a limitation in the number of JDBC connections that the VaultServer can open.

Otherwise an SQL1224N error is triggered when the vault is started.

So, if you had initially an AIX vault with a local DB2 server (resulting from a standard installation, a migration of a former configuration, ...) you need to modify the database connectivity for the vault.

You will have to run the appropriate db2 commands to catalog your local database under an alias which will be accessible through a client/server connection. (typically, "db2 catalog tcpip node" + "db2 catalog database at node" statements)

Then you will have to update your Vault server java properties, referencing the new db2 alias as the VaultServer_DBName parameter.

Here is how to by-pass this limitation:

  1. Install a DB2 client on the AIX server.
  2. Catalog the Vault database on the DB2 client.
  3. Set up the VaultServer in order to connect the database through the DB2 client instead of the DB2 server.



Modifying the Vault Server to Use Java Runtime Environment (JRE)



Edit the runENOVVaultServer shell:


and make the following changes.

Add the following before the echo "Starting ENOVIA V5 VAULT SERVER..... statement

export JAVA_HOME=/usr/java5 (where /usr/java5 is the install path for the JRE 1.5 code)

export PATH=$JAVA_HOME/bin:$PATH

Stop the Vault Server, if running, to ensure it will use the JRE 1.5 the next time it starts.