After the system is in a quiescent state and backed up, you can safely start the upgrade procedure.
If you upgraded your database arrange for the DBA to import the saved database information, including schema information and stored procedures. Consult your database server documentation for instructions.
After you have backed up your pre-4.3 installation, you are ready to install the new version of InterChange Server. To install the new version of InterChange Server, see Installing InterChange Server, XML data handler, e-Mail adapter, and other supporting products for instructions.
Notes:
If you are upgrading from a 4.2.2 version of InterChange Server, you do not need to configure the Object Request Broker. Proceed to the instructions inUpgrading server scripts.
As of the 4.2.2 release of InterChange Server, the VisiBroker ORB has been replaced by the IBM Java ORB. As described in Upgrading hardware and supporting software, the ICS Installer automatically installs the IBM Java ORB and the IBM Transient Naming Server as part of the ICS installation process. However, you must ensure that the IBM Java ORB is configured properly by performing the following tasks:
Various ORB-related properties were present in the VisiBroker ORB for tuning the ORB. If you have used these properties in any customized scripts or software, you must verify that they are set for the IBM Java ORB appropriately. Table 32 lists some of the VisiBroker ORB properties and their equivalent names in the IBM Java ORB.
If you have any customized scripts from pre-4.2.2 installations that reference VisiBroker ORB properties, substitute them with their IBM ORB equivalents listed below in Table 32.
Table 32. IBM ORB properties and their VisiBroker equivalents
IBM ORB properties | Equivalent VisiBroker properties | Description |
---|---|---|
org.omg.CORBA.ORBInitialHost | vbroker.agent.addr | Specifies the IP address or host name of the machine running the IBM Transient Naming Server (tnameserv). The default value for this property is localhost. |
org.omg.CORBA.ORBInitialPort | vbroker.agent.port | Specifies the port on which the IBM Transient Naming Server listens. |
com.ibm.CORBA.ListenerPort | vbroker.se.iiop_tp.scm.iiop_tp. listener.port | The port on which the ORB server will listen for incoming requests. If this property is specified, the ORB will start listening during ORB.init(). By default, this port is dynamically assigned. For 4.3 the VisiBroker property name OAport will continue to be supported. |
com.ibm.CORBA.LocalHost | vbroker.se.iiop_tp.host | This property represents the host name (or IP address) of the machine that the ORB is running on. The local host name is used by the server-side ORB to place the sever's host name into the IOR of a remote object. If this property is not set then the local host is retrieved by calling: InetAddress.getLocalHost(). getHostAddress();. For 4.3, the VisiBroker property name OAipAddr will continue to be supported. |
com.ibm.CORBA.ThreadPool. MaximumSize | vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMax | Specifies the maximum number of threads that the Server Connection Manager can create. The default value 0 implies that there are no restrictions. For 4.3, the VisiBroker property name OAthreadMax will continue to be supported. |
com.ibm.CORBA.ThreadPool. InactivityTimeout | vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMaxIdle | Specifies the amount of time (in seconds) before an idle thread will be destroyed. For 4.3, the VisiBroker property name of OAthreadMaxIdle will continue to be supported. |
com.ibm.CORBA.BufferSize | vbroker.orb.streamChunkSize | The number of bytes (as a GIOP message) that will be read from a socket on the first attempt. A larger buffer size increases the probability of reading the entire message in one attempt, which can improve performance. The default is 2048. |
In pre-4.2.2 versions of InterChange Server, the VisiBroker ORB provided the osfind tool to identify all ORB objects registered with InterChange Server. The IBM Java ORB provides a tool called CosNameServer_Dump for this purpose. This tool is located in the ProductDir/bin directory. For more information, see the System Administration Guide.
As of the 4.2.2 release of InterChange Server, the IBM Java ORB replaced the VisiBroker ORB. With this change, the Transient Naming Server replaced the VisiBroker Smart Agent, which was previously used for HA. For more information about configuring the IBM ORB for the HA environment, see Installing and Configuring the Object Request Broker (ORB).
If you have created custom files in your pre-existing InterChange Server system, you need to assess the following files to determine whether they require upgrading:
As of the 4.2.2 release of InterChange Server, all startup scripts were changed to accommodate the move from the VisiBroker ORB to the IBM Java ORB and support for the IBM JRE.
If you have customized any server startup scripts and you are upgrading to 4.3 from a release other than 4.2.2, you must make similar changes to the new scripts. You might need to make the following customizations to these startup scripts:
For example, if you have any customized data handlers, add their .jar files in the CLASSPATH variable.
After you have completed the upgrade process and its testing, you can remove the -design option from the server startup so that InterChange Server starts in production mode.
One of the tasks of the tool-configuration file, cwtools.cfg, is to provide custom .jar files to be included at compile time. If you have created custom .jar files, you must add these custom files to the codeGeneration section, in the CLASSPATH variable. The cwtools.cfg file is located in the following directory on the Windows machine running your Tools:
ProductDir\bin
All system environment variables are set in a single CWSharedEnv.sh file. All startup scripts read this file as part of their invocation procedure. It is in this file that ICS-system-wide properties (such as those for the IBM Java ORB) are set. As part of your upgrade process, make sure that the following system-wide properties are correctly set:
For more information on the CWSharedEnv.sh file, see the System Administration Guide.
If you have any completely custom components that use repository tables (such as scripts, database tables, or stored procedures), you must assess each component to determine whether it must be upgraded. For example, if a stored procedure uses a repository table that has changed in the new release, you must modify this stored procedure to work with the new structure of the repository table.
After the installation completes, you can start the new version of InterChange Server using your existing version of the repository, provided that all of the required supporting software is running. If you have upgraded with in-place upgrade of the database you must point ICS to the original repository. To start up ICS, follow these steps:
For instructions on how to verify that supporting software is running, refer to Starting supporting software and Starting the IBM ORB Transient Naming Server.
For instructions on how to start InterChange Server, refer to Starting InterChange Server and Starting System Manager.
You can check the InterchangeSystem.log file in the ProductDir directory to confirm a successful startup.
The InterChange Server repository is a database that holds metadata about InterChange Server components. You can perform the upgrade with in-place database upgrade or without. The 4.3 ICS Installer does not automatically upgrade the contents of your ICS repository. However, if in-place upgrade is used then when you started ICS in the previous step, ICS upgrades the schema in your pre-4.3 repository with any 4.3 changes. At this point of the upgrade process, you must decide which objects to load in the repository:
Installer automatically copies appropriate input files for the various components of ICS into ProductDir and various subdirectories of ProductDir, including /repository (where ProductDir is the product directory for the new 4.3 release). These input files contain the new components for the 4.3 ICS release.
If you backed up your ICS repository with repos_copy, you have one or more repository files that contain the repository objects for components from your pre-existing ICS release.
You can use the InterChange Server Component Management view in System Manager on a connected Windows machine to browse the components loaded into the server.
The steps described in this section are required only if you are upgrading InterChange Server without in-place upgrade of the database.
As part of the ICS installation process, you specified the names of these ICS databases in the ICS Configuration Wizard. When you started the new version of ICS, the server upgraded the schema in the repository database. To initialize this new repository, you must load pre-existing repository objects.
To prepare for loading the repository, take the following steps:
ProductDir/DLMs/classes/NativeMaps
ProductDir/collaborations/classes/UserCollaborations
where ProductDir is the product directory for the new 4.3 release. This step ensures that the .class files for your existing maps and collaborations reside in the new 4.3 directory structure.
Each of these steps to loading the repository is described in the sections that follow.
The steps in this section are required only if you are upgrading from version 4.1.1.
Check your existing repos_copy backup file (called a repository file) to ensure that all values are relevant to the new repository. Create a backup copy of your existing repository file and edit the original repository file to fix the following information:
When you import relationships, you must verify that the following attributes for each relationship are valid within the repository file:
If these attributes identify a database that cannot be found during the repos_copy import to the ICS repository, InterChange Server rolls back the entire import operation. However, if you delete these attributes for each relationship, InterChange Server uses the repository as the default relationship database.
Database connection pools in the 4.1.1 format cannot be imported into the new repository. Therefore, you must delete any connection pools from the repository file. After the ICS instance is upgraded, you must recreate these connection pools within System Manager on a connected Windows machine.
Clearing out the new repository
Before you import the pre-existing repository objects, you must delete any duplicate objects that might already exist in the 4.3 repository. This step is necessary because the repos_copy utility does not recognize the -ar or -arp options (which handle duplicate objects) when it imports an older format into the repository. If ICS finds any duplicate objects in the repository file, it rolls back the entire import operation.
To delete these repository objects, use the -d option of the repos_copy utility. For example, the following repos_copy command deletes the contents of the repository:
repos_copy -sNewICSinstance -uadmin -ppasswd -d
In the preceding repos_copy command:
To load the contents of the repository files into the repository, use the repos_copy utility. As described in Backing up the InterChange Server system, you should have exported your pre-existing repository objects with the -o option of the repos_copy utility to create one or more repository files. You now import these repository objects into the new repository with the -i option of repos_copy.
For example, suppose you have the Repository411.txt repository file. The following repos_copy command loads all repository objects within this file:
repos_copy -iRepository411.txt -sserverName -uuserName -ppassword -r*
In the preceding repos_copy command:
After the pre-existing repository objects are in the new repository, you must still perform additional steps to complete the upgrade of collaboration templates and maps. For more information, see Completing collaboration template and map upgrades.