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:

YourUnloaddir/$OSDS/reffiles/DBMS/ddl

The $OSDS value could be either aix_a or aix_a64 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 drop_VPM_VAULTFILE.xxx and the revoke_VPM_VAULTFILE.xxx 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:

VPM_VAULTFILE.xxx                             VPM_VAULTFILE_MyVault.xxx

grant_VPM_VAULTFILE.xxx                     grant_VPM_VAULTFILE_MyVault.xxx

drop_VPM_VAULTFILE.xxx                      drop_VPM_VAULTFILE_MyVault.xxx

revoke_VPM_VAULTFILE.xxx                   revoke_VPM_VAULTFILE_MyVault.xxx

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 VPM_VAULTFILE_MyVault.xxx file and the related grant file (grant_VPM_VAULTFILE_My_Vault.xxx) 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
export IT_CONFIG_PATH

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.

Example:

With the values below:

Install_dir: UNIXInstallPath/aix_a
Machine: reverdsy
VaultServerName: ENOVIAVaultServer
Env_name: ENOVIAV5VPMEnvironmentName
Env_dir: /CATEnv
MyVaultOwner_UID: 1400
MyVaultOwner_GID: 360

We get:

IT_CONFIG_PATH= UNIXInstallPath/aix_a/startup/orbix
export IT_CONFIG_PATH

Putit -h reverdsy -shared ENOVIAVaultServer "UNIXInstallPath/aix_a/startup/orbix/code/command/catstart -env \""ENOVIAV5VPMEnvironmentName"\" -direnv \""/CATEnv"\" --run UNIXInstallPath/aix_a/startup/orbix/code/command/runENOVVaultStarter -object \""1400 360 ENOVIAV5VPMEnvironmentName /CATEnv\""""

chmodit ENOVIAVaultServer i+all
chmodit ENOVIAVaultServer l+all

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

YourUnloaddir/$OSDS/startup/orbix/config/Repositories/ImpRep

Then you have created the Orbix service name ENOVIAVaultServer.

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

/home/DS/EnvNameSuffix/aix_a/startup/orbix/config/Repositories/ImpRep.

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/EnvNameSuffix/aix_a/code/command/runENOVVaultStarter 1415 363

Note about Orbix On AIX

The Orbix connection from an ENOVIA App Server launched by an Orbix Daemon A to a Vault Server fails if the Vault Server is running on the same machine and has not been launched by the same Orbix Daemon A.

The recommended by-pass is to deploy the Vault Server on a dedicated machine which is not shared with the ENOVIA App Servers. If it is not possible to have a dedicated machine, then the same Orbix daemon has to be used for ENOVIA App Server and the Vault Server.

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:

install_dir/docs/java

The default filename is no longer VaultServer.properties, but:

VaultServerName.properties

VaultServer setting purpose

VaultServer settings are used to manage:

• ORB parameters (Orbix implementation)
• Database connection and connection pool parameters
• Vault repositories
• Thread number
• Trace activation
• Optional behaviors: NFS mode, Cache, DB2 DATALINK.

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
VaultServer_ClientRequestTimeout: CORBA request timeout for outgoing CORBA request from Vault Server to a Vault Cache (default: 60000) (unit: millisecond)

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:

•  Client/Server communication parameters
• Trace activation
• Accessible VaultServer declaration through the VaultAliasName notion.

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: 

unload_dir/$OSDS/docs/java

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:

VaultServer_PropertiesFilePath=/u/lego/VAULTServer/PropertiesVersionNumber
export VaultServer_PropertiesFilePath
VaultServer_PropertiesFileName=CustomVaultServer.properties
export VaultServer_PropertiesFileName
VaultClient_PropertiesFilePath=/u/lego/VAULTClient/PropertiesVersionNumber
export VaultClient_PropertiesFilePath
VaultClient_PropertiesFileName=CustomVaultClient.properties
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.

Example:

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:

Repo0:

/VAULTCXR8/DirOfRepo0/TmpDirOfRepo0

/VAULTCXR8/DirOfRepo0/SecDir0OfRepo0

/VAULTCXR8/DirOfRepo0/SecDir1OfRepo0

Repo1

/VAULTCXR8/DirOfRepo1/tmp

/VAULTCXR8/DirOfRepo1/secured0

/VAULTCXR8/DirOfRepo1/secured1

/VAULTCXR8/DirOfRepo1/secured2

Repo2

/VAULTCXR8/DirOfRepo2/tmp

/VAULTCXR8/DirOfRepo2/secured0

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 dispatches 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.

Here is how the file dispatch algorithm works on several Vault repositories

When the application needs a repo to store a file, the following steps are done:

1. Free disk space is calculated for each repo.
2. Then, the percentage of the sum of the above disk space is calculated for each repo.
3. Then, a range between 1-100 is associated to each repo depending on the percentage above.
4. A random number between 1 and 100 is obtained by a call to the java method Math.random
5. The repo in which the file will be stored is selected following the random number above and the range of each repo determined by step 3.

So the files are dispatched according to statistical rules.

Example:

Case with three Vault repositories : Repo1, Repo2, Repo3

Assumptions:

• Free disk space for Repo1 is 25000 KB
• Free disk space for Repo2 is 25000 KB
• Free disk space for Repo3 is 50000 KB

Percentage and range for each repo:

• percentage for Repo1: 25 %
• range for Repo1: 1 - 25
• percentage for Repo2: 25 %
• range for Repo2: 26 - 50
• percentage for Repo3: 50 %
• range for Repo3: 51 - 100

So by applying the statistical rules, the Repo3 will be chosen twice more than Repo1 or Repo2.

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: 

DB2INSTANCE=admclien
export DB2INSTANCE

CLASSPATH issue on vault server side for JDBC use: add  db2client_home_directory/sqllib/java/db2java.zip 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:

NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1
export NLS_LANG

ORACLE_HOME has to be set. For instance:

ORACLE_HOME=/u/env/oracle/SunOS
export ORACLE_HOME

TNS_ADMIN has to be set. For instance:

TNS_ADMIN=/u/env/oracle/SunOS/network/adminµ
export TNS_ADMIN

CLASSPATH issue on vault server side for JDBC use:

UNIX:

Add $ORACLE_HOME/jdbc/lib/classes111.zip and $ORACLE_HOME/jdbc/lib/nls_charset11.zip to your CLASSPATH

Windows Server (64 bit): 

Add [ORACLE_HOME]\jdbc\lib\classes111.zip and [ORACLE_HOME]\jdbc\lib\nls_charset11.zip 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:

Unix:

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

Windows Server (64 bit):

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.

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)

On UNIX

Edit the runENOVVaultServer shell:

$InstallPath/$OSDS/code/command/runENOVVaultServer

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.