ENOVIA Windows Vault Database Migration From V5R17 To V5R18

Introduction

These instructions apply only to migrating the Vault database. This process is required for successful migration from R17 to R18. However, you must also run the standard ENOVIA V5 VPM migration separately in order to achieve a complete migration from R17 to R18.

Remember that Vault data may be contained in the regular ENOVIA V5 VPM database (the same one that contains all the production data) or it may be in a separate database, or both. You will need to run this migration once for each database that contains Vault data. If you are uncertain about the location of your vault data, you should determine the names of all the databases that contain vault data before starting this Vault Migration script. You can only run this migration script on one database at a time. If you have multiple Vault databases, you will have to run the Vault database migration multiple times.

These instructions assume you have completed the standard ENOVIA V5 VPM database migration. If you have not completed it, please stop and run the ENOVIA V5 VPM database migration first.

These instructions do not cover migration of a Unix database. This is covered in a separate document.

These instructions do not cover migration of the Vault environment. This is covered in a separate document. You must change the ENOVIA V5 VPM environment in R18 to be able to use the R17 vault files. You must perform both the Vault environment changes and the Vault Database Migration in order to access the same vault information in R18 that you were using in R17.

Vault Database Migration Instructions

MAKE AN OFFLINE BACKUP OF ALL VAULT DATABASES and copy them to tape before starting any migration.
Ensure that you are migrating directly from V5R17 to V5R18. These procedures do not support any other releases or migration effort. Do not attempt to use any other releases of ENOVIA V5 VPM with these instructions. Also ensure that your V5R18 Vault path points to the same path as your V5R17 Vault.
Ensure that you have a working V5R17 installation, including a completely functional Oracle or DB2 database that conforms to the required level of Oracle or DB2 software and is up and running before beginning migration. There should be no users connected to ENOVIA LCA or the database at the time of migration.
Logon to the ENOVIA LCA product server with the ENOVIA administrator ID that you defined during your enoviadbsetup. This will be the same admnistrator ID that you used to run the regular database migration. DO NOT attempt to run the database migration as root.
cd to the code/command directory under your R18 product install path. This path will appear something like one of these:

~/aix_a/code/command ~/solaris_a/code/command ~/hp_b/code/command

under the directory where you installed the product.
Create (for example, using the notepad editor) a batch file containing all the parameters you will need to run the migration script. The parameters should all wrap continuously as one line; there should be no carriage return. The batch file must have the suffix .bat to be executable. If it does not exceed the operating system limit for the length of a line, you could also type these commands directly onto a command line instead of using a command file.
If you are using a DB2 database, you will need to launch this vault database migration command line or command file from a DB2 command window. You can generate this window by going to a C:/ shell prompt or an MKS toolkit Korn shell and typing the command db2cmd. If you are using Oracle, you will need to launch this command from an MKS toolkit Korn shell. Failure to use the correct shell documented in this step will cause the script to fail. Other shells and command lines are not supported.

The parameters are:

DBVendor : ORACLE or DB2
DBName : Database name
DBAdmHome : Database administrator home directory
(for userid that created the database in Oracle or DB2)
DBAID : Database administrator ID (a user-id that has DBA permissions; may be different from the ID that owns the tables)
IdxTbsName : Tablespace name for indexes inside the database
TbsName : Tablespace name for tables inside the database (can be the same as IdxTbsName)

For command line help with this script, simply type Upgrade518_Vault.sh -h and press Enter from the Unix command line and it will return some help text.

Here is a sample of 2 executable files, one for Oracle and one for DB2. Notice the placement of the quotation marks and the direction of the slash “\” character:

ORACLE:

"C:\B18\intel_a\code\bin\catstart" -run "sh C:\B18\intel_a\code\command\Upgrade518NT_Vault.sh -DBVendor ORACLE -DBName BOLODB -DBAdmHome C:\ora102 -DBAID vpm2adm -TbsName ENOTBS -IdxTbsName ENOTBS –tmp C:\migration\R18"

DB2:

"C:\B18D01\intel_a\code\bin\catstart" -run "sh C:\B18\intel_a\code\command\Upgrade518NT_Vault.sh -DBVendor DB2 -DBName DB17 -DBAdmHome C:\DB2 -DBAID lcaadm -TbsName ENOTBS -IdxTbsName ENOTBS -tmp C:\migration\R18"
chmod 700 vault.bat (where vault.bat is the command file you created in #6 above) You must give the full rights to execute this file to the ENOVIA Administrator ID which will run the upgrade shell using chgrp/chmod UNIX commands (the user identified above in Step #4).
Execute the vault.bat script from command line (For example: .\vault.bat or ./vault.bat ). You will be prompted to enter the password for the DBAID. This password will appear on the screen when you type it, so you must take steps to safeguard the privacy of this password.
Informational status messages will appear. At the end of the script a message will appear clearly indicating the outcome of all the steps. Note that one of the steps (when running with Oracle database) will pause at a step that attempts to connect to the database. It advises that if this step does not complete in less than 2 minutes, you should interrupt it and diagnose the reason for the failure of Oracle connections. If this connection failure (or hung condition) occurs, the best way to diagnose the problem is to attempt to connect to Oracle while running as the same userid that was executing the migration, using a command line like this:

sqlplus DBAID/Password@DATABASE

This should return an error that your database administrator can diagnose. Common causes for failure include:
- Environment failure – not having the ORACLE_HOME value set properly or the PATH does not include $ORACLE_HOME/bin
- Wrong database name
- Wrong user-ID or wrong password
- Oracle listener not running
- tnsnames.ora file not containing the DATABASE name
- database not started (use the Oracle startup command)
- incorrect database admin home path on the migration script command line
Once the database connection issues are resolved, you can restart the script from the beginning.
In case of failure, go to the directory you specified for the -tmp parameter and ensure that all *518* files are preserved. Some of them will be needed by Support to determine the cause and solution to the problem. Move these files to a safe location before running the program again. The script is completely restartable. If it fails for any reason, you can relaunch it without any actions needed to clean up.
Below is some sample output showing the results of a successful run of Upgrade518NT_Vault.sh

Now working on tables owned by these Users: EV5ADM5 Now working on EV5ADM5... Checking db2 results... Number of DB2 errors found was: 0 Successfully completed update of DBNAME EV5ADM5 tables. Status of R17->R18 Vault Migration = SUCCESS
You can verify the results by looking in the directory you designated in the –tmp option and viewing the file: Upgrade518NT_Vault_internal.log This file has a log of the actions that were taken on your database.
Vault database migration should take less than 5 minutes. If you find that the process is running longer than this, most likely something is wrong. See the tips above about what to do if the process gets hung.

ENOVIA UNIX Vault Database Migration From V5R17 To V5R18

Introduction

These instructions apply only to migrating the Vault database. This process is required for successful migration from R17 to R18. However, you must also run the standard ENOVIA V5 VPM migration separately in order to achieve a complete migration from R17 to R18.

Remember that Vault data may be contained in the regular ENOVIA V5 VPM database (the same one that contains all the production data) or it may be in a separate database, or both. You will need to run this migration once for each database that contains Vault data. If you are uncertain about the location of your vault data, you should determine the names of all the databases that contain vault data before starting this Vault Migration script. You can only run this migration script on one database at a time. If you have multiple Vault databases, you will have to run the Vault migration multiple times.

These instructions assume you have completed the standard ENOVIA V5 VPM database migration. If you have not completed it, please stop and run the standard migration first.

These instructions do not cover migration of a Windows database. This is covered in a separate document.

These instructions do not cover migration of the Vault environment. This is covered in a separate document. You must change the ENOVIA V5 VPM environment in R18 to be able to use the R17 vault files. You must perform both the Vault environment changes and the Vault Database Migration in order to access the same vault information in R18 that you were using in R17.

Vault Migration Instructions:

MAKE AN OFFLINE BACKUP OF ALL VAULT DATABASES and copy them to tape before starting any migration.
Ensure that you are migrating directly from V5R17 to V5R18. These procedures do not support any other releases or migration effort. Do not attempt to use any other releases of ENOVIA V5 VPM with these instructions. Also ensure that your V5R18 Vault path points to the same path as your V5R17 Vault.
Ensure that you have a working V5R17 installation, including a completely functional Oracle or DB2 database that conforms to the required level of Oracle or DB2 software and is up and running before beginning migration. There should be no users connected to ENOVIA LCA or the database at the time of migration.
Logon to the ENOVIA LCA product server with the ENOVIA administrator ID that you defined during your enoviadbsetup. This will be the same administrator ID that you used to run the regular database migration. DO NOT attempt to run the migration as root.
cd to the code/command directory under your R18 product install path. This path will appear something like one of these:
~/aix_a/code/command ~/solaris_a/code/command ~/hp_b/code/command

under the directory where you installed the product.
Create (for example, using the vi editor) a command file (e.g.vault.sh) containing all the parameters you will need to run the migration script, starting the command with the ./catstart –run prefix. The parameters should all wrap continuously as one line; there should be no carriage return. If it does not exceed the operating system limit for the length of a line, you could also type these commands directly onto a command line instead of using a command file.

The parameters are:

DBVendor : ORACLE or DB2
DBName : Database name
DBAdmHome : Database administrator home directory (for userid that created the database in Oracle or DB2)
DBAID : Database administrator ID (a user-id that has DBA permissions; may be different from the ID that owns the tables)
IdxTbsName : Tablespace name for indexes inside the database
TbsName : Tablespace name for tables inside the database (can be the same as IdxTbsName)

For command line help with this script, simply type Upgrade518_Vault.sh -h and press Enter from the Unix command line and it will return some help text.

Here is a sample of 2 executable files, one for Oracle and one for DB2:

ORACLE:

/installpath/R18/aix_a/code/command/catstart -run "Upgrade518_Vault.sh -DBVendor ORACLE -DBName ORA1718 -DBAdmHome /oracle/app/oracle/product/9.2.0 -DBAID dbausr -IdxTbsName ENOIDX -TbsName ENOTBS -tmp /tmp/mig"
DB2:

./catstart -run "Upgrade518_Vault.sh -DBVendor DB2 -DBName DB1718 -DBAdmHome /home/db2adm -DBAID dbausr -IdxTbsName ENOTBS -TbsName ENOTBS -tmp /tmp/vaultmig"
chmod 700 vault.sh (where vault.sh is the command file you created in #6 above) You must give the full rights to execute this file to the ENOVIA Administrator ID which will run the upgrade shell using chgrp/chmod UNIX commands (the user identified above in Step #4).
Execute the vault.sh script from Unix command line (For example: ./vault.sh ). You will be prompted to enter the password for the DBAID. This password will not appear on the screen when you type it.
Informational status messages will appear. At the end of the script a message will appear clearly indicating the outcome of all the steps. Note that one of the steps (when running with Oracle database) will pause at a step that attempts to connect to the database. It advises that if this step does not complete in less than 2 minutes, you should press the Control-D buttons on your keyboard to interrupt it and diagnose the reason for the failure of Oracle connections. If this connection failure (or hung condition) occurs, the best way to diagnose the problem is to attempt to connect to Oracle on your Unix command line while running as the same userid that was executing the migration, using a command line like this:

sqlplus DBAID/Password@DATABASE

This should return an error that your database administrator can diagnose. Common causes for failure include:
- Environment failure – not having the ORACLE_HOME value set properly or the PATH does not include $ORACLE_HOME/bin
- Wrong database name
- Wrong user-ID or wrong password
- Oracle listener not running
- tnsnames.ora file not containing the DATABASE name
- database not started (use the Oracle startup command)
- incorrect database admin home path on the migration script command line
Once the database connection issues are resolved, you can restart the script from the beginning.
In case of failure, cd to the directory you specified for the -tmp parameter and ensure that all *518* files are preserved. Some of them will be needed by Support to determine the cause and solution to the problem. Move these files to a safe location before running the program again. The script is completely restartable. If it fails for any reason, you can relaunch it without any actions needed to clean-up.
Below is some sample output showing the results of a successful run of Upgrade518_Vault.sh

Now working on tables owned by these Users: EV5ADM5 Now working on EV5ADM5... Checking db2 results... Number of DB2 errors found was: 0 Successfully completed update of DBNAME EV5ADM5 tables. Status of R17->R18 Vault Migration = SUCCESS
You can verify the results by looking in the directory you designated in the –tmp option and viewing the file: Upgrade518_Vault_internal.log This file has a log of the actions that were taken on your database.
Vault database migration should take less than 5 minutes. If you find that the process is running longer than this, most likely something is wrong. See the tips above about what to do if the process gets hung.

Migrating a Vault Server Manually

This document will show you how to migrate manually a Vault Server. This vault migration documentation is for UNIX workstation only.

Migration Concepts

To migrate a Vault Server, the root concept is to create an R18 Vault that reuses existing Vault repositories from a previous version and connect a migrated database. This migration is implemented in four steps:

1. Data structure Migration
2. Vault Server creation
3. Useless data deletion
4. Vault settings update

Note: when you have an installation comprising multiple vaults, you must migrate each vault one by one by following the procedure documented below.

Data Structure Migration

Data structures are not systematically modified in each release. For example, data structures have not been changed in R18, so you can skip this step for R18.

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

YourUnloaddir/$OSDS/reffiles/DBMS/ddl

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:

upgrade517_VPM_VAULTFILE.clp and upgrade517_VPM_VAULTFILE.sql when creating R18 new Vault tables
grant_VPM_VAULTFILE.clp and grant_VPM_VAULTFILE.sql when creating grants on tables

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

To do so:

MAKE AN OFFLINE BACKUP OF ALL VAULT DATABASES and copy them to tape before starting any migration.
Ensure that you are migrating directly from V5R17 to V5R18. These procedures do not support any other releases or migration effort. Do not attempt to use any other releases of ENOVIA LCA with these instructions. Also ensure that your V5R18 Vault path points to the same path as your V5R17 Vault.
Ensure that you have a working V5R16 installation, including a completely functional Oracle or DB2 database that conforms to the required level of Oracle or DB2 software and is up and running before beginning migration. There should be no users connected to ENOVIA LCA or the database at the time of migration.
Log as root User.
Duplicate the following files and rename them as indicated below:
Original file name                                  Duplicated file name

upgrade517_VPM_VAULTFILE.xxx            upgrade517_VPM_VAULTFILE_MyVault.xxx
grant_VPM_VAULTFILE.xxx                     grant_VPM_VAULTFILE_MyVault.xxx
Change the name of the structure owner (the default owner is VPMADM) and the tablespaces name for table and for index if necessary. In the case of the grant file, we advise you to change the "to public" right into "to vault_db_cnx_user". That "vault_db_cnx_user" is the user specified in the VaultServer.properties file for the VaultServer_DBUser property.
Execute the upgrade517_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

Example:

If the database structure owner is SES and the tablespace for table and index is USERSPACE1 then, the SQL statement:

create table "VPMADM"."VAULTCHK" ( OID varchar(64) ,TYPE varchar(64) ,ATTR varchar(128) ,URL varchar(256) ,VOID varchar(16) for bit data ,DOCSIZE integer ,DOCLOCATION varchar(508) ,TAGTYPE integer ,LASTUPDATEDATE timestamp ) IN "TSTVPM" INDEX IN "TSIVPM" ; has to be updated to: create table "SES"."VAULTCHK" ( OID varchar(64) ,TYPE varchar(64) ,ATTR varchar(128) ,URL varchar(256) ,VOID varchar(16) for bit data ,DOCSIZE integer ,DOCLOCATION varchar(508) ,TAGTYPE integer ,LASTUPDATEDATE timestamp ) IN "USERSPACE1" INDEX IN "USERSPACE1" ;

Vault Server Creation

Once the vault database has been migrated, you have to create a new R18 Vault server corresponding to the R16 Vault you want to migrate. To do so, use the VaultSetup tool in batch mode or interactive mode. For more information, refer to Setting Up the Vault Server.

Beware: the VaultSetup tool create database structures and directories for that new Vault server. So you will have to remove that useless creation.

In the context of a Vault migration, use the VaultSetup tools as the following:

Keep the R16 VaultServerName for the R18 one.
Keep the R16 VaultAdministrator for the R18 one.
Use a test or unused database to create the database structures, keep in mind that you will have to drop them after Vault Server creation.

BEWARE: do not use the migrated database to create the database structures.
Use a temporary or unused directory to create the Vault repositories directories, keep in mind that you will have to remove them after Vault Server creation. Creates only one Vault repository, it is the minimum number required by the VaultSetup tool.

BEWARE: Do not use the true Vault directories (R16 ones) to create the R18 VaultServer repositories.

Useless data deletion

You will find here after how to remove the useless database structures and directories created by the Vault setup tool.

Database structures

Log as root User.
Duplicate the following files and rename them as indicated below:
Original file name Duplicated file name.
drop_VPM_VAULTFILE.xxx drop_VPM_VAULTFILE_MyVault.xxx
Change the name of the structure owner (the default owner is VPMADM). Execute the drop_VPM_VAULTFILE_MyVault.xxx file on the test database you have used to create the R18 Vault:

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

BEWARE: do not remove the Vault database structure of the migrated R16 database.

Example:

If the structure owner is SES the line:

drop table "VPMADM"."VAULTDOCUMENT";

has to be updated to :

drop table "SES"."VAULTDOCUMENT";

Directories

Log as root User.
Remove the R18 Vault repositories directories (see rm Unix command).

BEWARE: do not remove the R16 Vault repositories directories.

Vault Setting Update

Vault server setting update

The vault server property file has to be changed in order to access the vault to migrate repositories and to connect the migrated vault database.

The VaultSetup tool has created a XXXVaultServer.properties file under the directory:

install_dir/docs/java

(default name is ENOVIAVaultServer.properties). That file has to be replaced by a copy of the vault server properties file of the R16 vault you want to migrate.

Then, edit that file and update the following parameters depending on your R18 Vault server installation:

VaultServer_HostName VaultServer_DaemonPort VaultServer_DBName (Warning: the value to set is the name of the migrated database: in the sample below, it is DBSES)

Example:

R18 Vault server properties file before update:

## Vault Server Properties File ## Orbix parameters VaultServer_Name = ENOVIAVaultServer VaultServer_HostName = TITI1DSY VaultServer_DaemonPort = 1572 VaultServer_TimeOut = 54000000 ## Request execution parameters VaultServer_ThreadNumber = 2 VaultServer_TimeZoneRawOffset = 0 ## Database connection pool parameters VaultServer_DBMINPoolSize = 4 VaultServer_DBMAXPoolSize = 6 ## Database connection parameters VaultServer_DBName = DBSESR18 VaultServer_DBVendor = Oracle
VaultServer_DBUser = SES VaultServer_DBPassword = 252C252C ## Other parameters VaultServer_VaultAdministrator = ses VaultServer_ReadOnly = false VaultServer_LogRemovedFiles = false VaultServer_RemoveFiles = true VaultServer_AuthorizeNfsAccess = false VaultServer_Trace = OFF ## Repositories parameters VaultServer_NumOfRepo = 1 VaultServer_DBSchema = SES VaultServer_Repo_0_Name = MyRepo1 VaultServer_Repo_0_ReadOnly = false VaultServer_Repo_0_Path = E:\\tmp\\MyRepo1 VaultServer_Repo_0_TmpDirName = tmp VaultServer_Repo_0_NumOfSecDir = 1 VaultServer_Repo_0_SecDirName_0 = Secured

R16 Vault server properties file:

## Vault Server Properties File ## Orbix parameters VaultServer_Name = ENOVIAVaultServer VaultServer_HostName = JANE1DSY VaultServer_DaemonPort = 1570 VaultServer_TimeOut = 54000000
## Request execution parameters VaultServer_ThreadNumber = 2 VaultServer_TimeZoneRawOffset = 0 ## Database connection pool parameters VaultServer_DBMINPoolSize = 4 VaultServer_DBMAXPoolSize = 6 ## Database connection parameters VaultServer_DBName = DBSES VaultServer_DBVendor = Oracle VaultServer_DBUser = SES VaultServer_DBPassword = 252C252C ## Other parameters VaultServer_VaultAdministrator = ses VaultServer_ReadOnly = false VaultServer_LogRemovedFiles = false VaultServer_RemoveFiles = true VaultServer_AuthorizeNfsAccess = false VaultServer_Trace = OFF ## Repositories parameters VaultServer_NumOfRepo = 1 VaultServer_DBSchema = SES VaultServer_Repo_0_Name = MyRepo1 VaultServer_Repo_0_ReadOnly = false VaultServer_Repo_0_Path = E:\\users\\ses\\MyRepo1 VaultServer_Repo_0_TmpDirName = tmp VaultServer_Repo_0_NumOfSecDir = 2 VaultServer_Repo_0_SecDirName_0 = Secured VaultServer_Repo_0_SecDirName_1 = secured2

R18 Vault server properties file after update:

## Vault Server Properties File ## Orbix parameters VaultServer_Name = ENOVIAVaultServer VaultServer_HostName = TITI1DSY VaultServer_DaemonPort = 1572 VaultServer_TimeOut = 54000000 ## Request execution parameters VaultServer_ThreadNumber = 2 VaultServer_TimeZoneRawOffset = 0 ## Database connection pool parameters VaultServer_DBMINPoolSize = 4 VaultServer_DBMAXPoolSize = 6 ## Database connection parameters VaultServer_DBName = DBSES VaultServer_DBVendor = Oracle VaultServer_DBUser = SES VaultServer_DBPassword = 252C252C ## Other parameters VaultServer_VaultAdministrator = ses VaultServer_ReadOnly = false VaultServer_LogRemovedFiles = false VaultServer_RemoveFiles = true VaultServer_AuthorizeNfsAccess = false VaultServer_Trace = OFF ## Repositories parameters VaultServer_NumOfRepo = 1 VaultServer_DBSchema = SES VaultServer_Repo_0_Name = MyRepo1 VaultServer_Repo_0_ReadOnly = false VaultServer_Repo_0_Path = E:\\users\\ses\\MyRepo1 VaultServer_Repo_0_TmpDirName = tmp VaultServer_Repo_0_NumOfSecDir = 2 VaultServer_Repo_0_SecDirName_0 = Secured VaultServer_Repo_0_SecDirName_1 = secured2

VaultClient setting update

If you have some specific parameters in the VaultClient.properties file you have in R16, you should transfer those customizations in the R18 VaultClient.properties file generated by the VaultSetup tool.

Note: Do not forget to propagate the updated VaultClient settings, once generated, throughout your R18 migrated domain.

Example:

In the following example, the migrated Vault is the ENOVIAVaultServer one.

R18 VaultClient properties before update:

## Vault Client Properties File ## File read protocol VaultClient_ReadProtocol = 3 VaultClient_ReadProtocol_0 = CORBA VaultClient_ReadProtocol_1 = NFS VaultClient_ReadProtocol_2 = HTTP ## File write protocol VaultClient_WriteProtocol = 2 VaultClient_WriteProtocol_0 = CORBA VaultClient_WriteProtocol_1 = NFS ## File transfer protocol activation VaultClient_Active_ReadProtocol = CORBA VaultClient_Active_WriteProtocol = CORBA ## Data BlockSize parameter VaultClient_BlockSize = 1048576 ## Trace parameter VaultClient_Trace = OFF ## Default alias name VaultClient_DefaultAliasName = ENOVIAVaultServer

## Vault server alias ENOVIAVaultServer VaultClient_ENOVIAVaultServer_ReadVaultServerName = ENOVIAVaultServer VaultClient_ENOVIAVaultServer_ReadVaultServerHostName = TITI1DSY VaultClient_ENOVIAVaultServer_ReadVaultServerDaemonPort = 1572 VaultClient_ENOVIAVaultServer_WriteVaultServerName = ENOVIAVaultServer VaultClient_ENOVIAVaultServer_WriteVaultServerHostName = TITI1DSY VaultClient_ENOVIAVaultServer_WriteVaultServerDaemonPort = 1572

R16 VaultClient properties:

## Vault Client Properties File ## File read protocol VaultClient_ReadProtocol = 3 VaultClient_ReadProtocol_0 = CORBA VaultClient_ReadProtocol_1 = NFS VaultClient_ReadProtocol_2 = HTTP ## File write protocol VaultClient_WriteProtocol = 2 VaultClient_WriteProtocol_0 = CORBA VaultClient_WriteProtocol_1 = NFS ## File transfer protocol activation VaultClient_Active_ReadProtocol = CORBA VaultClient_Active_WriteProtocol = CORBA ## Data BlockSize parameter VaultClient_BlockSize = 3048576 ## Trace parameter VaultClient_Trace = OFF ## Default alias name VaultClient_DefaultAliasName = ENOVIAVaultServer

## Vault server alias ENOVIAVaultServer VaultClient_ENOVIAVaultServer_ReadVaultServerName = ENOVIAVaultServer VaultClient_ENOVIAVaultServer_ReadVaultServerHostName = JANE1DSY VaultClient_ENOVIAVaultServer_ReadVaultServerDaemonPort = 1570 VaultClient_ENOVIAVaultServer_ReadProtocol = HTTP VaultClient_ENOVIAVaultServer_ReadHTTPServerHost = JANE1DSY VaultClient_ENOVIAVaultServer_ReadHTTPServerPort = 8080 VaultClient_ENOVIAVaultServer_WriteVaultServerName = ENOVIAVaultServer VaultClient_ENOVIAVaultServer_WriteVaultServerHostName = JANE1DSY VaultClient_ENOVIAVaultServer_WriteVaultServerDaemonPort = 1570 ## Vault server alias Vault2 ## Use HTTP file transfer protocol (read operations only) VaultClient_Vault2_ReadVaultServerName = Vault2 VaultClient_Vault2_ReadVaultServerHostName = bayeux VaultClient_Vault2_ReadVaultServerDaemonPort = 1576 VaultClient_Vault2_WriteVaultServerName = Vault2 VaultClient_Vault2_WriteVaultServerHostName = bayeux VaultClient_Vault2_WriteVaultServerDaemonPort = 1576

R18 VaultClient properties after update:

## Vault Client Properties File ## File read protocol VaultClient_ReadProtocol = 3 VaultClient_ReadProtocol_0 = CORBA VaultClient_ReadProtocol_1 = NFS VaultClient_ReadProtocol_2 = HTTP ## File write protocol VaultClient_WriteProtocol = 2 VaultClient_WriteProtocol_0 = CORBA VaultClient_WriteProtocol_1 = NFS ## File transfer protocol activation VaultClient_Active_ReadProtocol = CORBA VaultClient_Active_WriteProtocol = CORBA ## Data BlockSize parameter VaultClient_BlockSize = 3048576 ## Trace parameter VaultClient_Trace = OFF ## Default alias name VaultClient_DefaultAliasName = ENOVIAVaultServer

The HTTP read protocol has been added and updated to the right machine. The BlockSize has also been updated. The Vault2 alias declaration has not been copied because we only migrated in that example the ENOVIAVaultServer Vault.