Running co-existing installations of WebSphere Application Server on a single machine

Last updated: 11/14/2002

This article describes various co-existence scenarios that WebSphere Application Server supports and the steps required to achieve co-existence.

What is meant by "co-existence of WebSphere"?

Co-existence of WebSphere encompasses any of the following:

As part of co-existence, you can configure a single Web server for multiple instances or releases of WebSphere Application Server or configure a separate instance of a Web server for each instance or release of WebSphere Application Server.

Planning for co-existence

Before you install WebSphere Application Server, consider the following issues:

  1. Do you need to upgrade WebSphere supporting software to have co-existing installations of WebSphere Application Server? For co-existence of WebSphere Application Server Version 3.5 and WebSphere Application Server Version 4.0, you must upgrade software so it supports WebSphere Application Server Version 4.0; that is, you must use software that is common among the releases. For example, levels of Web servers common among WebSphere Application Server Versions 3.5 and 4.0 include: IBM HTTP Server 1.3.19, Apache HTTP Server 1.3.20, iPlanet Web Server 4.1 SP7, Lotus Domino 5.0.6, and Microsoft IIS 4.0 on Windows NT and 5.0 on Windows 2000. Examine the WebSphere supporting software Web page at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html to see if you can use common levels of supporting software for your desired installations.

  2. Do you need to resolve conflicts in the desired configurations? Supported configurations include:

    Determine whether you need a single instance of a Web server with mutiple instances of WebSphere Application Server or a separate instance of a Web server with each instance of WebSphere Application Server. See "Configuring Web servers" for details on selecting a single Web server instance or multiple Web server instances.

  3. Does the machine have enough system resources to handle co-existence? Based on system requirements for each instance, determine if your system has enough resources to support co-existence.

  4. Will you need to install WebSphere Application Server FixPaks (PTFs)?

    If you do need to install PTFs, you must address issues such as the following for Windows: when installing Version 3.5 PTFs earlier than 3.5.5, the PTF installer uses WAS_HOME to determine the location of where to install the PTF. If installing 3.5.4 or earlier PTFs when Version 4.0 or later releases is already installed, the PTF installer will install into the Version 4.0 WebSphere directory. Before installing a PTF earlier than Version 3.5.5, update the WAS_HOME entry to point to WebSphere Application Server Version 3.5 and, after the installation completes, switch it back to the Version 4.0 location.

Installing various supported configurations

This section describes how to install the supported configurations. References to Version 3.5 includes 3.5 and all later releases and FixPaks. References to Version 4.0 includes 4.0 and all later releases and FixPaks.

Enabling co-existence of WebSphere Application Server Version 3.5 and WebSphere Application Server Advanced Edition Version 4.0, where both use a common Web server

Assuming Version 3.5 is already installed on your system, complete the following steps to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support co-existing installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for iPlanet Web Server) so that you can repair inadvertent mistakes in configurations.
  5. Install WebSphere Application Server Advanced Edition Version 4.0. For co-existence of Versions 3.5 and 4.0, specify a different database for your repository when prompted by the Version 4.0 installation program. Also, specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, do not select any Web server plug-in.
  6. After successfully installing WebSphere Application Server Advanced Edition Version 4.0, create the database that is specified in the install screens (for example, WAS40). On Windows with DB2 as the repository, the specified database will be created when system reboots.
  7. Fix the Web server HTTP configuration to support both releases of WebSphere Application Server.
  8. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Edition, add com.ibm.ejs.sm.adminServer.lsdPort=9001 and com.ibm.ejs.sm.adminServer.bootstrapPort=901 to the 4.0 admin.config file in the \WebSphere40\AppServer\bin directory. Select an unused port. Write down the name of the bootstrap port.
  9. Configure a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  10. Start both releases of WebSphere Application Server.
  11. Run tools as needed to support co-existence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In co-existence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For example, if the bootstrap port is 901, to start the administrative client on Windows, enter adminclient.bat localhost 901. For information, see "Using WebSphere Application Server tools."

  12. Stop the WebSphere Application Server administrative server.

    Note that, on Windows, if both versions are running and the administrative server (either Version 3.5 or 4.0) is stopped using the Services panel, the last-started application server stops and leaves the other instance running, but the Services panel shows both instances as stopped. Thus, use the WebSphere administrative console to stop an administrative server (stop the node).

Enabling co-existence of WebSphere Application Server Version 3.5 and later releases and WebSphere Application Server Advanced Single Server Edition Version 4.0 and later releases, where both use a common Web server

Assuming Version 3.5 is already installed on your system, complete steps such as those described in this section to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support co-existing installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for iPlanet Web Server) so that you can repair inadvertent mistakes in configurations.
  5. Install WebSphere Application Server Advanced Single Server Edition Version 4.0. For co-existence of Versions 3.5 and 4.0 specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, do not select any Web server plug-in.
  6. Fix the Web server HTTP configuration to support both releases of WebSphere Application Server.
  7. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Single Server Edition, open an editor on the \WebSphere40\AppServer\config\server-cfg.xml file and find the element 
    <locationServiceDaemon
  xmi:id="LocationServiceDaemon_1" hostname="localhost"
  port="9000" mode="NONE"/>

    Change the port to 9001. Next, find the element

    <orbSettings xmi:id="ORBConfig_1" enable="true"
  bootstrapHost="localhost" bootstrapPort="900">

    Change the bootstrapPort to 901.

  8. Configure a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  9. Start both releases of WebSphere Application Server.
  10. Run tools as needed to support co-existence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In co-existence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For information, see "Using WebSphere Application Server tools."

Enabling co-existence of WebSphere Application Server Version 3.5 and and later releases and WebSphere Application Server Advanced Edition Version 4.0 and later releases using separate instances of a Web server

Assuming Version 3.5 is already installed on your system, complete steps such as those described in this section to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support co-existing installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Create a second instance of the Web server. For IBM HTTP Server, see "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5." Write down the port number that is being used for the second instance of the Web server.
  5. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for iPlanet Web Server) so that you can repair inadvertent mistakes in configurations.
  6. Install WebSphere Application Server Advanced Edition Version 4.0. For co-existence of Versions 3.5 and 4.0, specify a different database for your repository when prompted by the Version 4.0 installation program. Also, specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, select the Web server plug-in that you need to supoort a second instance of the Web server. If you are using IBM HTTP Server, the installation program does not give the option of creating a second instance configuration file; thus, after installation, fix the Web server configuration manually.
  7. After successfully installing WebSphere Application Server Advanced Edition Version 4.0, create the database that is specified in the install screens (for example, WAS40). On Windows with DB2 as the repository, the specified database will be created when system reboots.
  8. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Edition, add com.ibm.ejs.sm.adminServer.lsdPort=9001 and com.ibm.ejs.sm.adminServer.bootstrapPort=901 to the 4.0 admin.config file in the \WebSphere40\AppServer\bin directory. Select an unused port. Write down the name of the bootstrap port.
  9. Configure a virtual host to support the second Web server instance, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  10. Start both releases of WebSphere Application Server.
  11. Run tools as needed to support co-existence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In co-existence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For example, if the bootstrap port is 901, to start the administrative client on Windows, enter adminclient.bat localhost 901. For information, see "Using WebSphere Application Server tools."

  12. Stop the WebSphere Application Server administrative server.

    Note that, on Windows, if both versions are running and the administrative server (either Version 3.5 or 4.0) is stopped using the Services panel, the last-started application server stops and leaves the other instance running, but the Services panel shows both instances as stopped. Thus, use the WebSphere administrative console to stop an administrative server (stop the node).

Enabling co-existence of WebSphere Application Server Version 3.5 and WebSphere Application Server Advanced Single Server Edition Version 4.0 using separate instances of a Web server

Assuming Version 3.5 is already installed on your system, complete steps such as those described in this section to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support co-existing installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Create a second instance of the Web server. For IBM HTTP Server, see "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5."
  5. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for iPlanet Web Server) so that you can repair inadvertent mistakes in configurations.
  6. Install WebSphere Application Server Advanced Single Server Edition Version 4.0. For co-existence of Versions 3.5 and 4.0, specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, select your Web server plug-in to create a second instance of the Web server.
  7. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Single Server Edition, open an editor on the \WebSphere40\AppServer\config\server-cfg.xml file and find the element 
    <locationServiceDaemon
  xmi:id="LocationServiceDaemon_1" hostname="localhost"
  port="9000" mode="NONE"/>

    Change the port to 9001. Next, find the element

    <orbSettings xmi:id="ORBConfig_1" enable="true"
  bootstrapHost="localhost" bootstrapPort="900">

    Change the bootstrapPort to 901.

  8. Configure a virtual host to support a second Web server instance, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  9. Start both releases of WebSphere Application Server.
  10. Run tools as needed to support co-existence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In co-existence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For information, see "Using WebSphere Application Server tools."

Enabling co-existence of multiple instances of WebSphere Application Server Advanced Single Server Edition Version 4.0 from a single installation using a single instance of a Web server

This section describes how to configure multiple instances of one installation of WebSphere Application Server Advanced Single Server Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Single Server Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, for each instance of the Advanced Single Server Edition, complete the steps below.

Configuring two instances
  1. Make two copies of the server-cfg.xml file and name the copies server-cfg1.xml and server-cfg2.xml.
  2. Define unique ports within the configuration XML files. The unique ports that need to be different are listed below, along with the port numbers used for this example. Specify the ports in the server configuration files. You can use different port numbers. The port numbers listed for Instance 1 are the default supplied with server-cfg.xml. Choose ports that no other applications use.
    Port used for... Instance 1 Instance 2 XML element in .xml file
    HTTP transport port 9080 9081 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_1" hostname="*"
port="9081">
    HTTPs 9443 9444 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_2" hostname="*" port="9444"
sslEnabled="true">
    Administrative console 9090 9091 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_3" hostname="*" port="9091"
external="false">
    Bootstrap 900 901 
    <orbSettings xmi:id="ORBConfig_1" enable="true"
bootstrapHost="localhost" bootstrapPort="901">
    LSD 9000 9001 
    <locationServiceDaemon
xmi:id="LocationServiceDaemon_1"
hostname="localhost" port="9001" mode="NONE"/>
    OLT 2102 2103 
    <objectLevelTraceSettings
xmi:id="ObjectLevelTrace_1" enable="false"
hostname="localhost" port="2103" debug="false"
sourcePath=""/>
    Administrative debugging 7000 7001 
    <traceService xmi:id="TraceServiceConfig_1"
enable="true" traceSpecification="*=all=disabled"
traceOutputFilename="stdout"
diagThreadPort="7001"/>
  3. Define a virtual host entry for HTTP transport. For Instance 2, define ports 9081 and 9091 in the virtual host list of the server-cfg2.xml file.
  4. Define unique file names or directory names within the server configuration file. Below are the file names that need to be unique. To define unique names, you can use the administrative console or edit the server configuration .xml file. The default files are shown in brackets. If you change the directory, ensure that the directory already exists.
    Log files
    [ $(LOG_ROOT)/default_stderr.log and default_stdout.log ]

    You can change the log file names or the LOG_ROOT directory name.

    Passivation directory
    [ $(WAS_ROOT)/temp ]

    Security key file name, if used
    [ $(WAS_ROOT)/etc/DummyServerKeyFile.jks ] and
    [ $(WAS_ROOT)/etc/DummyServerTrustFile.jks ]

    The key file name only needs to be different if you want to use a different key ring file on each server.

    Transaction log
    [ $(TRANLOG)/tran1.log ] and [ ${TRANLOG_ROOT}/tran2.log ]

    Installed application directory
    [ $(APP_INSTALL_ROOT) ]

    The directory name only needs to be different if you want to have two different applications with the same .ear file name installed on the two servers. You define the actual applications that will run on a particular server instance in the server configuration file, and not by changing the contents of the installedApps directory. Therefore, two server instances can share the same directory and still run different applications.

    APP_INSTALL_ROOT is a path map entry that you change using the administrative console or by editing the server configuration .xml file.

    Note that there are hard coded paths to the installedApps directory for sample resources. You must change these paths.

    LOG_ENTRY and TRANLOG_ENTRY are path map entries that you change using the administrative console or by editing the server configuration .xml file. To edit the .xml file manually, search for the elements defining LOG_ENTRY or TRANLOG_ENTRY and modify the location. For example:

    <entries xmi:id="PathMapEntry_2" symbolicName="LOG_ROOT" path="${WAS_ROOT}/logs"
description="The file system path to the directory which will contain server log files."/>
  5. Specify a different directory for JSP generated code and compiled code if two instances will not share the same directory. Specify the directory through a system property com.ibm.websphere.servlet.temp.dir. In the server-cfg2.xml file, specify the system property in JVM settings as follows: 
    <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
  verboseModeGarbageCollection="false" verboseModeJNI="false" initialHeapSize="0"
  maximumHeapSize="256" runHProf="false" debugMode="false"
  genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT="false">
<systemProperties xmi:id="SystemProperty_1" name="com.ibm.websphere.servlet.temp.dir"
  value="E:/WebSphere/AppServer/mytemp"/>
</jvmSettings>
  6. To specify an instance-specific activity.log file, do the following:
    1. Copy the WAS_HOME/properties/logging.properties file to a named file, for example, mylogging.properties.
    2. Open an editor for the mylogging.properties file and change the com.ibm.was.ras.ActivityLogName property.
    3. Specify the file name using the system property com.ibm.ws.ras.RasProperties.

      An example follows: 

      <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
  verboseModeGarbageCollection="false" verboseModeJNI="false"
initialHeapSize="0"
  maximumHeapSize="256" runHProf="false" debugMode="false"
  genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT
="false">
<systemProperties xmi:id="SystemProperty_1" name
="com.ibm.websphere.servlet.temp.dir" value="E:\WebSphere\AppServer"/>
<systemProperties xmi:id="SystemProperty_2" name
="com.ibm.ws.ras.RasProperties"
  value="mylogging.properties"/>
</jvmSettings>

    In order for the setting change to work properly, the mylogging.properties file must be in the application server classpath. If the WAS_HOME/properties directory is already in the application server classpath, no change needed.

  7. If the two instances require different security settings, copy the sas.*.props files (sas.server.props and sas.client.props) located in the directory \WebSphere\AppServer\properties and modify the files as needed. (See the Version 4.0 InfoCenter for information on these files.) Open an editor on the \WebSphere\AppServer\bin\setupCmdLine(sh/bat) file and change SERVERSAS, CLIENTSAS, WSCPCLIENTSAS settings to point to the new properties file; and then save the setupCmdLine(sh/bat) file with a different name (for example, setupCmdLine2(sh/bat)). Also, modify the startServer(sh/bat) file to invoke setupCmdLine2(sh/bat) and save the startServer(sh/bat) file as startServer2(sh/bat).
  8. Copy the installed applications directory to the new installedApps directory (or create an empty directory). You only need to do this step if you decided above to have separate application directories.
  9. Set up a single, shared Web server instance. Manually merge the plugin-cfg.xml files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command 
      GenPluginCfg.(bat/sh) -configFile server1_configuration_file -outputFile /temp/server1_directory
    2. Run the command 
      GenPluginCfg.(bat/sh) -configFile server2_configuration_file -outputFile /temp/server2_directory
    3. Manually merge the contents of the two files into the WebSphere_installation_root/config/plugin-cfg.xml file.
  10. Start the servers.
Starting the servers

To start the servers on Windows platforms, run the commands:

$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg2.xml

To start the servers on UNIX platforms, run the commands:

$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg2.xml

Note that if you have changed the sas.*.props files and renamed the startServer file for a second instance, use startServer2(sh/bat) to start the second instance.

Enabling co-existence of WebSphere Application Server Advanced Single Server Edition Version 4.0 from a single installation using multiple instances of a Web server

This section describes how to configure multiple instances of one installation of WebSphere Application Server Advanced Single Server Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Single Server Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, for each instance of the Advanced Single Server Edition, complete the steps below.

Configuring two instances
  1. Make two copies of the server-cfg.xml file and name the copies server-cfg1.xml and server-cfg2.xml.
  2. Define unique ports within the configuration XML files. The unique ports that need to be different are listed below, along with the port numbers used for this example. Specify the ports in the server configuration files. You can use different port numbers. The port numbers listed for Instance 1 are the default supplied with server-cfg.xml. Choose ports that no other applications use.
    Port used for... Instance 1 Instance 2 XML element in .xml file
    HTTP transport port 9080 9081 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_1" hostname="*"
port="9081">
    HTTPs 9443 9444 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_2" hostname="*" port="9444"
sslEnabled="true">
    Administrative console 9090 9091 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_3" hostname="*" port="9091"
external="false">
    Bootstrap 900 901 
    <orbSettings xmi:id="ORBConfig_1" enable="true"
bootstrapHost="localhost" bootstrapPort="901">
    LSD 9000 9001 
    <locationServiceDaemon
xmi:id="LocationServiceDaemon_1"
hostname="localhost" port="9001" mode="NONE"/>
    OLT 2102 2103 
    <objectLevelTraceSettings
xmi:id="ObjectLevelTrace_1" enable="false"
hostname="localhost" port="2103" debug="false"
sourcePath=""/>
    Administrative debugging 7000 7001 
    <traceService xmi:id="TraceServiceConfig_1"
enable="true" traceSpecification="*=all=disabled"
traceOutputFilename="stdout"
diagThreadPort="7001"/>
  3. Define a virtual host entry for HTTP transport. For Instance 2, define ports 9081 and 9091 in the virtual host list of the server-cfg2.xml file.
  4. Define unique file names or directory names within the server configuration file. Below are the file names that need to be unique. To define unique names, you can use the administrative console or edit the server configuration .xml file. The default files are shown in brackets. If you change the directory, ensure that the directory already exists.
    Log files
    [ $(LOG_ROOT)/default_stderr.log and default_stdout.log ]

    You can change the log file names or the LOG_ROOT directory name.

    Passivation directory
    [ $(WAS_ROOT)/temp ]

    Security key file name, if used
    [ $(WAS_ROOT)/etc/DummyServerKeyFile.jks ] and
    [ $(WAS_ROOT)/etc/DummyServerTrustFile.jks ]

    The key file name only needs to be different if you want to use a different key ring file on each server.

    Transaction log
    [ $(TRANLOG)/tran1.log ]

    Installed application directory
    [ $(APP_INSTALL_ROOT) ]

    The directory name only needs to be different if you want to have two different applications with the same .ear file name installed on the two servers. You define the actual applications that will run on a particular server instance in the server configuration file, and not by changing the contents of the installedApps directory. Therefore, two server instances can share the same directory and still run different applications.

    APP_INSTALL_ROOT is a path map entry that you change using the administrative console or by editing the server configuration .xml file.

    Note that there are hard coded paths to the installedApps directory for sample resources. You must change these paths.

    LOG_ENTRY and TRANLOG_ENTRY are path map entries that you change using the administrative console or by editing the server configuration .xml file. To edit the .xml file manually, search for the elements defining LOG_ENTRY or TRANLOG_ENTRY and modify the location. For example:

    <entries xmi:id="PathMapEntry_2" symbolicName="LOG_ROOT" path="${WAS_ROOT}/logs"
description="The file system path to the directory which will contain server log files."/>
  5. Specify a different directory for JSP generated code and compiled code if two instances will not share the same directory. Specify the directory through a system property com.ibm.websphere.servlet.temp.dir. In the server-cfg2.xml file, specify the system property in JVM settings as follows: 
    <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
  verboseModeGarbageCollection="false" verboseModeJNI="false" initialHeapSize="0"
  maximumHeapSize="256" runHProf="false" debugMode="false"
  genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT="false">
<systemProperties xmi:id="SystemProperty_1" name="com.ibm.websphere.servlet.temp.dir"
  value="E:/WebSphere/AppServer/mytemp"/>
</jvmSettings>
  6. To specify an instance-specific activity.log file, do the following:
    1. Copy the WAS_HOME/properties/logging.properties file to a named file, for example, mylogging.properties.
    2. Open an editor for the mylogging.properties file and change the com.ibm.was.ras.ActivityLogName property.
    3. Specify the file name using the system property com.ibm.ws.ras.RasProperties.

      An example follows: 

      <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
  verboseModeGarbageCollection="false" verboseModeJNI="false"
initialHeapSize="0"
  maximumHeapSize="256" runHProf="false" debugMode="false"
  genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT
="false">
<systemProperties xmi:id="SystemProperty_1" name
="com.ibm.websphere.servlet.temp.dir" value="E:\WebSphere\AppServer"/>
<systemProperties xmi:id="SystemProperty_2" name
="com.ibm.ws.ras.RasProperties"
  value="mylogging.properties"/>
</jvmSettings>

    In order for the setting change to work properly, the mylogging.properties file must be in the application server classpath. If the WAS_HOME/properties directory is already in the application server classpath, no change needed.

  7. If the two instances require different security settings, copy the sas.*.props files (sas.server.props and sas.client.props) located in the directory \WebSphere\AppServer\properties and modify the files as needed. (See the Version 4.0 InfoCenter for information on these files.) Open an editor on the \WebSphere\AppServer\bin\setupCmdLine(sh/bat) file and change SERVERSAS, CLIENTSAS, WSCPCLIENTSAS settings to point to the new properties file; and then save the setupCmdLine(sh/bat) file with a different name (for example, setupCmdLine2(sh/bat)). Also, modify the startServer(sh/bat) file to invoke setupCmdLine2(sh/bat) and save the startServer(sh/bat) file as startServer2(sh/bat).
  8. Copy the installed applications directory to the new installedApps directory (or create an empty directory). You only need to do this step if you decided above to have separate application directories.
  9. Generate a plug-in configuration for each instance:
    1. Run the command 
      GenPluginCfg.(bat/sh) -configFile server1_configuration_file
    2. Run the command 
      GenPluginCfg.(bat/sh) -configFile server2_configuration_file -outputFile /temp/server2_directory
  10. Create a second instance of the Web server. Specify information for the WebSphere plug-in and the location of the plug-in configuration file (/temp/server2_directory) in the second instance of the Web server configuration file. See "Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0."
  11. Specify a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  12. Start the servers.
Starting the servers

To start the servers on Windows platforms, run the commands:

$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg2.xml

To start the servers on UNIX platforms, run the commands:

$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg2.xml

Note that if you have changed the sas.*.props files and renamed the startServer file for a second instance, use startServer2(sh/bat) to start the second instance.

Enabling co-existence of multiple domains of WebSphere Application Server Advanced Edition Version 4.0 from a single installation using a single instance of a Web server

This section describes how to configure multiple domains from one installation of WebSphere Application Server Advanced Edition.

  1. Install WebSphere Application Server Advanced Edition Version 4.0. For these steps, the installation root directory is \WebSphere\AppServer.
  2. Copy the admin.config file in the directory \WebSphere\AppServer, naming it admin-sec.config. If you have already started the WebSphere Application Server before making a copy, open an editor on the admin-sec.config file and change the following properties to true.
  3. Open an editor on the admin-sec.config file and make the following changes:
    1. Change the conflicting ports. Add the following to the bottom of the file: 
      com.ibm.ejs.sm.adminServer.lsdPort=9001
com.ibm.ejs.sm.adminServer.bootstrapPort=901
    2. Change the log file names. Edit the respective properties to the following. Note that the properties should each be on one line, though some appear here on more than one line to improve readability. 
      com.ibm.ejs.sm.adminServer.traceFile=I:/WebSphere/AppServer-AE/logs/tracefile-sec
com.ibm.ejs.sm.util.process.Nanny.traceFile=I:/WebSphere/AppServer-AE/logs/nanny-sec.trace
com.ibm.ejs.sm.adminServer.logFile=I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog1-sec,
  I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog2-sec
    3. Change the database name to was40sec: 
      com.ibm.ejs.sm.adminServer.dbdatabaseName=was40sec
  4. Copy the adminserver.(sh/bat) file in \WebSphere\AppServer\bin and name the copy adminserver-sec.(sh/bat).
  5. Optional: If you need different security settings for different domains, copy the \WebSphere\AppServer\properties\sas.server.properties file and change the copy to meet your needs. See the Version 4.0 InfoCenter for more details.
    1. Change the property com.ibm.CORBA.ConfigURL in the admin.config file to point to the new file. For example: 
      com.ibm.CORBA.ConfigURL=file:/f:/WebSphere/40/AE/properties/sas2.server.props
    2. Copy the setupCmdLine.(sh/bat) file and name it setupCmdLine-sec.(sh/bat). Then, open an editor on setupCmdLine-sec.(sh/bat) and change SERVERSAS to point to the new properties file. Also, if desired, change CLIENTSAS and WCSCLIENTSAS to point to the new files.
  6. Open an editor on the adminserver-sec.(sh/bat) file and change %WAS_HOME%\bin\admin.config to %WAS_HOME%\bin\admin-sec.config. If you changed the location of the sas.*.properties files in earlier steps, look for the setupCmdLine.(sh/bat) invocation in the adminserver-sec.(sh/bat) file and change adminserver-sec(sh/bat) to invoke the setupCmdLine-sec.(sh/bat) file.
  7. Start the first WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver.(sh/bat).
    3. Start the administrative console using the command adminclient.(sh/bat).
  8. Start the second WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command 
      adminclient.(sh/bat) localhost 901

      If you modified client CLIENTSAS properties in an earlier step, create a separate copy of the adminclient.(sh/bat) file to invoke the modified setupcmdline.(sh/bat) file and run the modified adminclient script for the second instance.

  9. If you are using the default server in the second domain, modify conflicting ports in the default server of the second domain. (If you are not using the default server in the second domain, this step is not required.)
    1. In the second administrative console started in the previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  10. To set up a single, shared Web server instance, manually merge the plugin-cfg.xml files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
    2. Run the command 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 900

      The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file and name it plugin-cfg1.xml.

    3. Run the command 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file and name it plugin-cfg2.xml.

    4. Manually merge the contents of the two files into the /WebSphere/AppServer/config/plugin-cfg.xml file.
  11. Change files and locations:
    1. Select the default server in the administrative console of the second domain.
    2. Specify different log files for the default server:
      1. Select File in the right-hand panel.
      2. Change the Standard Output and Standard Input file names so they are different from that of the first domain.
    3. Specify a different temporary directory for JSP files:
      1. Select JVM Settings in the right-hand panel.
      2. Specify the system property com.ibm.websphere.servlet.temp.dir=\WebSphere\AppServer\mytemp. See the Version 4.0 InfoCenter for more information on specifying system properties.

Enabling co-existence of multiple domains of WebSphere Application Server Advanced Edition Version 4.0 from a single installation using multiple instances of a Web server

This section describes how to configure multiple domains from one installation of WebSphere Application Server Advanced Edition.

  1. Install WebSphere Application Server Advanced Edition Version 4.0. For these steps, the installation root directory is \WebSphere\AppServer.
  2. Copy the admin.config file in the directory \WebSphere\AppServer, naming it admin-sec.config. If you have already started the WebSphere Application Server before making a copy, open an editor on the admin-sec.config file and change the following properties to true.
  3. Open an editor on the admin-sec.config file and make the following changes:
    1. Change the conflicting ports. Add the following to the bottom of the file: 
      com.ibm.ejs.sm.adminServer.lsdPort=9001
com.ibm.ejs.sm.adminServer.bootstrapPort=901
    2. Change the log file names. Edit the respective properties to the following. Note that the properties should each be on one line, though some appear here on more than one line to improve readability. 
      com.ibm.ejs.sm.adminServer.traceFile=I:/WebSphere/AppServer-AE/logs/tracefile-sec
com.ibm.ejs.sm.util.process.Nanny.traceFile=I:/WebSphere/AppServer-AE/logs/nanny-sec.trace
com.ibm.ejs.sm.adminServer.logFile=I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog1-sec,
  I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog2-sec
    3. Change the database name to was40sec: 
      com.ibm.ejs.sm.adminServer.dbdatabaseName=was40sec
  4. Copy the adminserver.(sh/bat) file in \WebSphere\AppServer\bin and name the copy adminserver-sec.(sh/bat).
  5. Optional: If you need different security settings for different domains, copy the \WebSphere\AppServer\properties\sas.server.properties file and change the copy to meet your needs. See the Version 4.0 InfoCenter for more details.
    1. Change the property com.ibm.CORBA.ConfigURL in the admin.config file to point to the new file. For example: 
      com.ibm.CORBA.ConfigURL=file:/f:/WebSphere/40/AE/properties/sas2.server.props
    2. Copy the setupCmdLine.(sh/bat) file and name it setupCmdLine-sec.(sh/bat). Then, open an editor on setupCmdLine-sec.(sh/bat) and change SERVERSAS to point to the new properties file. Also, if desired, change CLIENTSAS and WCSCLIENTSAS to point to the new files.
  6. Open an editor on the adminserver-sec.(sh/bat) file and change %WAS_HOME%\bin\admin.config to %WAS_HOME%\bin\admin-sec.config. If you changed the location of the sas.*.properties files in earlier steps, look for the setupCmdLine.(sh/bat) invocation in the adminserver-sec.(sh/bat) file and change adminserver-sec(sh/bat) to invoke the setupCmdLine-sec.(sh/bat) file.
  7. Start the first WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver.(sh/bat).
    3. Start the administrative console using the command adminclient.(sh/bat).
  8. Start the second WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command 
      adminclient.(sh/bat) localhost 901

      If you modified client CLIENTSAS properties in an earlier step, create a separate copy of the adminclient.(sh/bat) file to invoke the modified setupcmdline.(sh/bat) file and run the modified adminclient script for the second instance.

  9. If you are using the default server in the second domain, modify conflicting ports in the default server of the second domain. (If you are not using the default server in the second domain, this step is not required.)
    1. In the second administrative console started in the previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  10. To set up multiple instances of the Web server instance, generate the plugin-cfg.xml files for the two server instances:
    1. Run the command 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file and name it plugin-cfg2.xml.

    2. Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
    3. Run the command 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 900

      where node_name is the host name that appears in the WebSphere Application Server administrative console under the WebSphere administrative domain. The command generates \WebSphere\AppServer\config\plugin-cfg.xml.

  11. Create a second instance of the Web server. Specify information for the WebSphere plug-in and the location of the plug-in configuration file (/temp/server2_directory) in the second instance of the Web server configuration file. See "Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0."
  12. Specify a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  13. Change files and locations:
    1. Select the default server in the administrative console of the second domain.
    2. Specify different log files for the default server:
      1. Select File in the right-hand panel.
      2. Change the Standard Output and Standard Input file names so they are different from that of the first domain.
    3. Specify a different temporary directory for JSP files:
      1. Select JVM Settings in the right-hand panel.
      2. Specify the system property com.ibm.websphere.servlet.temp.dir=\WebSphere\AppServer\mytemp. See the Version 4.0 InfoCenter for more information on specifying system properties.

Enabling co-existence of multiple domains of WebSphere Application Server Advanced Edition Version 4.0 from multiple installations

This section describes how to run multiple instances of WebSphere Application Server Advanced Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the second instance of WebSphere Advanced Edition in a different location from that of previous installation (for example, /WebSphere/AppServer2/). If you use a different Web server instance for the second installation, choose that Web server configuration when installing. With IBM HTTP Server as the Web server, the installation program will not give you the option to select the second instance configuration file; thus, after successfully installing WebSphere Application Server, fix the IBM HTTP Server configuration manually. If you use a single instance of the Web server for both instances, do not select a plug-in in the installation program. Further, choose a different database repository than that of the previous installation.
  3. Open an editor on the /WebSphere/AppServer2/bin/admin-sec.config file and change the conflicting ports. Add the following to the bottom of the file: 
    com.ibm.ejs.sm.adminServer.lsdPort=9001
com.ibm.ejs.sm.adminServer.bootstrapPort=901
  4. Start the first WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver.(sh/bat).
    3. Start the administrative console using the command adminclient.(sh/bat).
  5. Start the second WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command 
      adminclient.(sh/bat) localhost 901

      If you modified client CLIENTSAS properties in an earlier step, create a separate copy of the adminclient.(sh/bat) file to invoke the modified setupcmdline.(sh/bat) file and run the modified adminclient script for the second instance.

  6. If you are using the default server in the second domain, modify conflicting ports in the default server of the second domain. (If you are not using the default server in the second domain, this step is not required.)
    1. In the second administrative console started in a previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  7. To set up a single, shared Web server instance, manually merge the plug-in configuration files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
    2. Run the command 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 900

      where node_name is the host name that appears in the WebSphere Application Server administrative console under WebSphere administrative domain. The command generates \WebSphere\AppServer\config\plugin-cfg.xml.

    3. Run the command 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates \WebSphere\AppServer2\config\plugin-cfg.xml.

    4. Manually merge the contents of the two generated files and replace both the files with the merged one.

Enabling co-existence of multiple instances of WebSphere Application Server Advanced Single Server Edition Version 4.0 from multiple installations

This section describes how to run multiple instances of WebSphere Application Server Advanced Single Server Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Single Server Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the second instance of WebSphere Advanced Single Server Edition in a different location from that of previous installation (for example, /WebSphere/AppServer2/). If you use a different web server instance for the second installation, choose that Web server configuration when installing. With IBM HTTP Server as the Web server, the installation program will not give you the option to select the second instance configuration file; thus, after successfully installing WebSphere Application Server, fix the IBM HTTP Server configuration manually. If you use a single instance of the Web server for both instances, do not select a plug-in in the installation program.
  3. Define unique ports within the configuration of the second installation XML file. The unique ports that need to be different are listed below, along with the port numbers used for this example. Specify the ports in the server configuration files. You can use different port numbers. The port numbers listed for Instance 1 are the default supplied with /WebSphere/AppServer2/server-cfg.xml. Choose ports that no other applications use.
    Port used for... Instance 1 Instance 2 XML element in .xml file
    HTTP transport port 9080 9081 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_1" hostname="*"
port="9081">
    HTTPs 9443 9444 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_2" hostname="*" port="9444"
sslEnabled="true">
    Administrative console 9090 9091 
    <transports
xmi:type="applicationserver:HTTPTransport"
xmi:id="HttpTransport_3" hostname="*" port="9091"
external="false">
    Bootstrap 900 901 
    <orbSettings xmi:id="ORBConfig_1" enable="true"
bootstrapHost="localhost" bootstrapPort="901">
    LSD 9000 9001 
    <locationServiceDaemon
xmi:id="LocationServiceDaemon_1"
hostname="localhost" port="9001" mode="NONE"/>
    OLT 2102 2103 
    <objectLevelTraceSettings
xmi:id="ObjectLevelTrace_1" enable="false"
hostname="localhost" port="2103" debug="false"
sourcePath=""/>
    Administrative debugging 7000 7001 
    <traceService xmi:id="TraceServiceConfig_1"
enable="true" traceSpecification="*=all=disabled"
traceOutputFilename="stdout"
diagThreadPort="7001"/>
  4. Define a virtual host entry for HTTP transport. For Instance 2, define ports 9081 and 9091 in the virtual host list of the server-cfg.xml file.
  5. If you are using a single Web server for both instances, to set up a single, shared Web server instance, manually merge the plugin-cfg.xml files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command 
      GenPluginCfg.(bat/sh) -configFile server1_configuration_file -outputFile  /temp/server1_directory
    2. Run the command 
      GenPluginCfg.(bat/sh) -configFile server2_configuration_file -outputFile /temp/server2_directory
    3. Manually merge the contents of the two files into the /WebSphere/AppServer/config/plugin-cfg.xml file.

Enabling co-existence of WebSphere Application Server Advanced Edition Version 4.0 and WebSphere Application Server Advanced Single Server Edition Version 4.0

This section describes how to run WebSphere Application Server Advanced Edition Version 4.0 and WebSphere Application Server Advanced Single Server Edition Version 4.0 on the same machine. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the WebSphere Advanced Edition in a different location from that of the WebSphere Advanced Single Server Edition previously installed (for example, /WebSphere/AppServer2/). If you want a different Web server instance for the second installation, choose that Web server configuration when installing. If you want to use a single instance of the Web server for both instances, do not select a plug-in in the installation program.
  3. Open an editor on the /WebSphere/AppServer2/bin/admin-sec.config file and change the conflicting ports. Add the following to the bottom of the file: 
    com.ibm.ejs.sm.adminServer.lsdPort=9001
com.ibm.ejs.sm.adminServer.bootstrapPort=901
  4. Start the WebSphere Application Server Advanced Single Server product:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run sartupServer(sh/bat).
  5. Start the WebSphere Application Server Advanced Edition product:
    1. Go to a command prompt and move to the \WebSphere\AppServer2\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command 
      adminclient.(sh/bat) localhost 901
  6. If you are using the default server in the Advanced Edition, modify conflicting ports in the default server of the Advanced Edition. (If you are not using the default server in the Advanced Edition, this step is not required.)
    1. In the Advanced Edition administrative console started in a previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  7. To set up a single, shared Web server instance, manually merge the plug-in configuration files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command for the Advanced Single Server Edition (shown here on two lines to improve readability): 
      /WebSphere/AppServer/GenPluginCfg.(bat/sh) -configFile server1_configuration_file
  -outputFile /temp/server1_directory

      The command generates /WebSphere/AppServer/config/plugin-cfg.xml.

    2. Run the command for the Advanced Edition: 
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates /WebSphere/AppServer2/config/plugin-cfg.xml.

    3. Manually merge the contents of the two generated files and replace both the files with the merged one.

Enabling co-existence of WebSphere Application Server Advanced Edition Version 3.5 and WebSphere Application Server Advanced Edition Version 4.0 with security on

When security is enabled, it is also needed to configure each instance with a different LSDSSL port which is not used. WebSphere Application Server Version 3.5 uses 9001 as LSDSSL port.

To specify LSDSSL port in WebSphere Application Server Advanced Edition Version 4.0, add the following property in the admin.config file: 

com.ibm.ejs.adminserver.lsdPort=9020    
com.ibm.CORBA.LSDSSLPort=9011

Configuring Web servers

This section covers the following:

Upgrading from IBM HTTP Server Version 1.3.12 to Version 1.3.19

To upgrade from IBM HTTP Server Version 1.3.12 to 1.3.19, do the following for the appropriate platform. The following steps assume that WebSphere Application Server Version 3.5 is installed with IBM HTTP Server Version 1.3.12. After upgrading to IBM HTTP Server Version 1.3.19, fix the configuration for WebSphere Application Server Version 3.5.

AIX
  1. Stop the IBM HTTP Server and IBM HTTP Administration servers.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Install IBM HTTP Server 1.3.19 over the existing 1.3.12 product using the smit option Update Installed Software to Latest Level (Update ALL) or the installp command: 
    installp_cmd -a -d 'IHS_source_directory -f' '_update_all' '-c' '-N' '-g' '-x'

To execute the new ikeyman installed with IBM HTTP Server, you might need to point ikeyman to the IBM Software Developer Kit installed with WebSphere. Set the JAVA_HOME environment variable to point to the software development kit and then run ikeyman.

HP-UX and Solaris
  1. Stop the IBM HTTP Server and IBM HTTP Administration servers.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Uninstall IBM HTTP Server Version 1.3.12 and then install IBM HTTP Server Version 1.3.19.

To execute the new ikeyman installed with IBM HTTP Server, you might need to point ikeyman to the system's Java Development Kit or to the Kit installed with WebSphere. Set the JAVA_HOME environment variable to point to Kit supported by WebSphere and then run ikeyman.

Windows NT or 2000
  1. In a Services dialog, stop the IBM HTTP Server and IBM HTTP Administration services.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Uninstall IBM HTTP Server 1.3.12.
  4. Install IBM HTTP Server 1.3.19.

Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5

UNIX

Open an editor on the httpd.conf file for IBM HTTP Server Version 1.3.19 and add the following lines at the bottom of the file based on your installation root. Following are the entries for Solaris. Check in the backed-up configuration file httpd-35.conf for the appropriate extensions for other UNIX platforms. For AIX, WebSphere Application Server usually installs into the /usr directory.

LoadModule ibm_app_server_module  /opt/WebSphere/AppServer/bin/mod_ibm_app_server.so
AddModule mod_app_server.c
NcfAppServerConfig BootFile  /opt/WebSphere/AppServer/properties/bootstrap.properties
Alias /IBMWebAS/  /opt/WebSphere/AppServer/web/

If the directory structure is not deleted when IBM HTTP Server 1.3.12 was uninstalled and IBM HTTP Server 1.3.19 is installed in the same location, settings in httpd.conf are preserved. In that case above steps are optional. Check the httpd.conf file to make sure entries are there in the file.

Windows NT

Open an editor on the httpd.conf file for IBM HTTP Server 1.3.19 and add the following lines at the bottom of the file. (These entries are in the backed-up httpd-35.conf file.) 

LoadModule ibm_app_server_module drive_letter:/WebSphere/AppServer/bin/mod_ibm_app_server.dll
NcfAppServerConfig BootFile drive_letter:\WebSphere\AppServer\properties\bootstrap.properties
Alias /IBMWebAS/ "drive_letter:/WebSphere/AppServer/web/"

Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 4.0

Websphere Application Server Version 4.0 requires the following entries in the HTTP configuration file for the Web server:

UNIX
LoadModule ibm_app_server_http_module/opt/WebSphere40/AppServer/bin/mod_ibm_app_server_http.so 
AddModule mod_app_server_http.c
Alias /Wssamples "/opt/WebSphere40/AppServer/WSsamples/"
WebSpherePluginConfig /opt/WebSphere40/AppServer/configplugin-cfg.xml

Note that the above entry for LoadModule points to the mod_ibm_app_server_http.so file, which is Solaris-specific. For other UNIX platforms specify the library accordingly by checking the file extension in the /WebSphere/AppServer/bin directory. For AIX, usually WebSphere Application Server installs under the /usr directory. So, change the file based on your installation root.

Windows NT or 2000
LoadModule ibm_app_server_http_module drive_letter:/WebSphere40/AppServer/bin/mod_ibm_app_server_http.dll 
Alias /Wssamples "drive_letter:/WebSphere40/AppServer/WSsamples/"
WebSpherePluginConfig drive_letter:\WebSphere40\AppServer\config\plugin-cfg.xml

Creating multiple instances of IBM HTTP Server for WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have upgraded to IBM HTTP Server Version 1.3.19 and configured IBM HTTP Server for Version 3.5 using the previous section.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and remove lines corresponding to Version 3.5. That is, remove the lines that added in the previous section, "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 4.0."
  2. Select the port for the second instance. Select the port that is not in use by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR: 
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid

HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command 

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command 
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command 

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command 
    apache-f .\conf\httpd2.conf

Creating and configuring multiple instances of IBM HTTP Server for a single installation of WebSphere Application Server Version 4.0

The following steps assume that you have installed WebSphere Application Server Version 4.0 and configured it for IBM HTTP Server 1.3.19.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and modify it to point to the second instance's WebSphere plug-in configuration file. For example: 
    WebSpherePluginConfig I:/WebSphere/AppServer/config/plugin-cfg2.xml
  2. Select the port for the second instance. Select the port that is not being used by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR: 
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid

HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command 

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command 
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command 

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command 
    apache-f .\conf\httpd2.conf

Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0

The following steps assume that you have installed WebSphere Application Server Version 4.0 and configured it for IBM HTTP Server 1.3.19.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and modify it to point to the second instance's WebSphere plug-in configuration file. For example: 
    WebSpherePluginConfig I:/WebSphere/AppServer2/config/plugin-cfg.xml
  2. Select the port for the second instance. Select the port that is not being used by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR: 
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid

HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command 

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command 
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command 

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command 
    apache-f .\conf\httpd2.conf

Configuring a single instance of a Web server with WebSphere Application Server Versions 3.5 and 4.0

The following section provides the steps required for using a single Web server with WebSphere Application Server Versions 3.5 and 4.0. When you use a single instance of a Web server with multiple instances of WebSphere, there cannot be a common Web context root present in both instances of WebSphere. If common context roots are present, then the last-configured plug-in will service the requests.

Configuring a single instance of IBM HTTP Server with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for IBM HTTP Server 1.3.19 and that you installed Version 4.0 without selecting the plug-in choice during installation.

To confgure a single instance, add the following lines at the bottom of the httpd.conf file of IBM HTTP Server based on your WebSphere Application Server Version 4.0 installation root.

UNIX

LoadModule ibm_app_server_http_module/opt/WebSphere/AppServer40/bin/mod_ibm_app_server_http.so 
AddModule mod_app_server_http.c
Alias /WSsamples "/opt/WebSphere/AppServer40/WSsamples/"
WebSpherePluginConfig /opt/WebSphere/AppServer40/configplugin-cfg.xml

Note that the above entry for LoadModule points to mod_ibm_app_server_http.so, which is Solaris-specific. For other UNIX platforms, specify the library according to the file extension in the /WebSphere/AppServer/bin directory. For AIX, WebSphere Application Server usually installs into the /usr directory.

Windows NT

LoadModule ibm_app_server_http_module e:/WebSphere/AppServer40/bin/mod_ibm_app_server_http.dll
Alias /WSsamples "e:/WebSphere/AppServer40/WSsamples/" 
WebSpherePluginConfig e:\WebSphere\AppServer40\config\plugin-cfg.xml
Configuring a single instance of iPlanet Web Server with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for iPlanet Web Server and that you installed WebSphere Application Server Version 4.0 without selecting the plug-in choice during installation.

To configure a single instance, add the following lines at the bottom of the obj.conf file of iPlanet Web Server based on your WebSphere Application Server Version 4.0 installation root.

UNIX

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="/opt/WebSphere40/AppServer/bin/libns41_http.so"
Init fn="as_init" bootstrap.properties=" /opt/WebSphere40/AppServer/config/plugin-cfg.xml"
Service fn="as_handler"

Note that the above entry for LoadModule points to libns41_http.so, which is Solaris-specific. For other UNIX platforms, specify the library according to the file extension in the /WebSphere/AppServer/bin directory. For AIX, WebSphere Application Server usually installs into the /usr directory.

Windows NT

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="E:\WebSphere40\AppServer\bin\libns41_http.dll"
Init fn="as_init" bootstrap.properties=" E:\WebSphere40\AppServer\config\plugin-cfg.xml" 
Service fn="as_handler"
Configuring a single instance of Microsoft IIS with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for IIS and that you installed WebSphere Application Server Version 4.0 without selecting the plug-in choice during installation.

  1. Start the Internet Service Manager application.
  2. Create a new Virtual Directory for the Web site instance you want to work with WebSphere Application Server. To do this with a default installation, expand the tree on the left until you see Default Web Site. Right-click on Default Web Site' and select New -> Virtual Directory. In the wizard for adding a Virtual Directory, do the following:
    1. In the space provided for Alias to be used to Access Virtual Directory, type sePlugins.
    2. In the space provided for Enter the physical path of the directory containing the content you want to publish, browse the WebSphere Application Server bin directory. For What access permissions do you want to set for this directory, check the Allow Execute Access check box.
    3. Click Finish and a virtual directory will be added to your default Web site entitled sePlugins.
  3. Add the ISAPI filter into the IIS configuration. Right-click on the host name in the tree on the left and select Properties. In the Properties dialog, do the following:
    1. On the Internet Information Services tab, select WWW Service in the Master Properties drop-down box and click Edit.
    2. In the WWW Service Master Properties window that opens, click on the ISAPI Filters tab and then the Add button. This opens the Filter Properties window.
    3. For Filter Name, type iisWASPlugin.
    4. For Executable, click Browse and go into the WebSphere bin directory and select the iisWASPlugin_http.dll file. Then, click OK until all open windows are closed.
  4. Add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE -> SOFTWARE -> IBM -> WebSphere Application Server -> 4.0. Set the value for this variable to the location of the plugin-cfg.xml file.
Configuring a single instance of Domino with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for Domino. Follow the steps to enable the HTTP Transport plug-in to work correctly with Domino Version 5.05 or 5.06. The following modifications are not made by the WebSphere installation program and must be performed manually.

  1. Start the Domino server.
  2. Access the file /webadmin.nsf using your Web browser (for example, http://hokie2ks.raleigh.ibm.com/webadmin.nsf). The browser should prompt you for a password. Give the short name for the administrator and the administrator password.
  3. Click on the Configuration link on the left side of the page.
  4. Click on the Servers link on the top-left center of the page.
  5. Double-click on the server you want to work with WebSphere Application Server.
  6. Click Edit Server on the top-left of the center window.
  7. Click Internet Protocols in the middle of the page.
  8. Under DSAPI in the middle-right of the page, add the path to the Domino plug-in. The plug-in is installed into the WebSphere Application Server bin directory.
  9. Click Save and Close on the upper-left of the center window.
  10. Define the location of the configuration file.

    UNIX

    Set the WAS_HOME environment variable to point to WebSphere Application Server Version 4.0 root directory.

    Windows

    Add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE -> SOFTWARE -> IBM -> WebSphere Application Server -> 4.0. Set the value for this variable to the location of the plugin-cfg.xml file.

  11. Restart the Domino server. When the server is starting, you should see something similar to the following: 
    02/12/2001 03:05:09 PM  JVM: Java Virtual Machine initialized.
WebSphere DSAPI filter loaded
02/12/2001 03:05:10 PM  HTTP Web Server started

Configuring virtual hosts in WebSphere Application Server Version 4.0

This section describes how to configure virtual hosts for Version 4.0. For general information on virtual hosts, see the Version 4.0 InfoCenter.

Configuring a virtual host for the Advanced Edition

  1. Write down the port used by the Web server configured for this WebSphere Application Server instance. For example, the port is 81.
  2. Start the administrative server and administrative client. In the administrative console, select Virtual Hosts, select the default_host in the right-hand pane, right click on the default_host, and select Properties.
  3. Add *.81 to the Host Aliases list and apply the changes.

Configuring a virtual host for the Advanced Single Server Edition

  1. Write down the port to be added to the list of virtual hosts. For example, the port is 81.
  2. Open the \WebSphere\AppServer40\config\server-cfg.xml file and add the above port (for example, 81) under virtual hosts: 
    <aliases xmi:id="HostAlias_5" hostname="*" port="81"/>

    Following is the sample section of the file after adding the above entry:

    <virtualHosts xmi:id="VirtualHost_1" name="default_host">
  <aliases xmi:id="HostAlias_1" hostname="*" port="9080"/>
  <aliases xmi:id="HostAlias_2" hostname="*" port="9443"/>
  <aliases xmi:id="HostAlias_3" hostname="*" port="80"/>
  <aliases xmi:id="HostAlias_4" hostname="*" port="443"/>
  <aliases xmi:id="HostAlias_5" hostname="*" port="81"/>
...

Uninstalling WebSphere Application Server

This section covers the following:

Uninstalling WebSphere Application Server Version 3.5 where there is a co-existant installation of WebSphere Application Server Version 4.0 FixPak 2 (4.0.2)

Uninstalling Version 3.5 on AIX

To uninstall Version 3.5 on AIX, do the following:

  1. Move to a command prompt for the /usr/lpp directory.
  2. Delete the package directories corresponding to the Version 3.5 installation. Remove the directories starting with IBMWebAS but not having the identifier WAS.

    WARNING: Do not remove the packages starting with IBMWEBAS.base.WAS.

  3. Run smit and remove Version 3.5.
Uninstalling Version 3.5 on Windows NT or 2000

You might encounter unexpected behavior when uninstalling an installation of WebSphere Application Server where there are co-existent installations. This section provides some additional steps that you might need to take when uninstalling Version 3.5 on Windows. It is recommended that you manually execute uninstse.exe for uninstalling Version 3.5 and uninstWAS40.exe for uninstalling WebSphere 4.0. These files are located in root directory of the installation. Note that, after installing 4.0, the Windows Add/Remove Programs Panel no longer indicates that 3.5 is installed, the only way to uninstall is using uninstse.exe command. After uninstalling 3.5, the Windows Add/Remove Programs Panel believes that Version 4.0 is no longer installed. The only way to uninstall 4.0 is to execute uninstWAS40.exe.

To uninstall Version 3.5 on Windows, go to the Websphere Application Server Version 3.5 directory \WebSphere35\AppServer and run uninstse.exe. The program will uninstall Version 3.5.

As a consequence of the uninstallation, if single instance of IBM HTTP Server is the Web server used, the WebSphere plug-in information for Version 4.0 is removed while the Version 3.5 plug-in is left in the configuration file. After uninstalling 3.5, validate that the Version 4.0 Web server configuration file is correct. Refer to "Configuring a single instance with WebSphere Application Server Versions 3.5 and 4.0" to find out the entries required in a Web server configuration file to support Version 4.0.

Uninstalling Version 3.5 or Version 4.0 on HP-UX (Defect 115384.RN)

If you have installed WebSphere Application Server Version 3.5 before installing Version 4.0 on your machine, you could receive the following error message when uninstalling Version 3.5: 

java.lang.NoClassDefFoundError: installer/util/PTFAndExtensionsUninstaller

Or, if you have installed WebSphere Application Server Version 4.0 after installing Version 3.5, you could receive the following error message when uninstalling Version 4.0: 

java.lang.NoZClassDefFoundError: JConfig

To work around this problem, perform one of the following steps:

Uninstalling WebSphere Application Server Version 4.0 Advanced Edition or Advanced Single Server Edition if there are multiple installations

The following section discusses uninstalling when you have more than one version of WebSphere Application Server Version 4.0 installed on your system.

UNIX

When you have multiple installations of WebSphere Application Server, packages contain information of only the last installation. Use uninstall.sh in the Websphere Application Server installation root to uninstall a particular installation.

Windows NT or 2000

When you have multiple installations of WebSphere Application Server, the registry contains information of only the last installation. In case of multiple installations of the Advanced Edition, the Services panel contains reference to only the last installation. To uninstall each Websphere Application Server installation, run a command such as the following in a command window:

c:\winnt\isuninst.exe -y -f WEBSPHERE_INSTALLATION_ROOT\DeISL1.isu

For example, to uninstall an installation in C:\WebSphere40\AppServer, run the command:

c:\winnt\isuninst.exe -y -f C:\WebSphere40\AppServer40\DeISL1.isu

Note that, when an instance of WebSphere Application Server is uninstalled, the Windows registry information for WebSphere Application Server is deleted (and the entry is removed from the Services panel if an Advanced Edition is uninstalled).

Using WebSphere Application Server tools

Use WebSphere Application Server tools as needed to support co-existence.

Updating the PATH variable for multiple tools on Windows

Installing WebSphere Application Server Version 4.0 on Windows updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example: PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from bin directory.

Specifying the bootstrap port

Specify the bootstrap port if it changes. In co-existence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For example, if the bootstrap port is 901, to start the administrative client on Windows, enter adminclient.bat localhost 901. Note that invoking such tools with the help option will provide information on how to specify the bootstrap port.

For the WSCP tool, to specify a different bootstrap port and host name, you must create a properties file specifying the details. See the Version 4.0 InfoCenter for details on using the WSCP tool.

Programmatic changes as to the bootstrap port

Make programmatic changes required for co-existence. For example, as noted above, you must configure different WebSphere Application Server instances with different bootstrap ports. While accessing the JNDI service by the clients running in a different process than that of the WebSphere process, specify the provider URL with the the bootstrap port. This is required only if bootstrap port is other than 900. For example:

Properties env = new Properties();
env.put("java.naming.provider.url",iiop://localhost:901);
InitialContext ic = new InitialContext(env);