Step 4: Complete the migration

This topic describes the manual steps that you might need to perform to complete the migration process. These are steps that are not performed automatically by the WebSphere Application Server migration tools.

Migrate the web server configuration
Use the following steps to migrate the plug-in configuration:

  1. Configure an HTTP server instance
    There are two options to chose from:

    • Create a new HTTP server instance to be used by the Websphere Version 6.0 profile. This method allows both Websphere Application Server Version 4.0.x, 5.0.x, or 5.1.x, and Version 6.0 profiles to continue operating correctly.

    • Update the HTTP server instance configuration for the Websphere Version 4.0.x, 5.0.x, or 5.1.x instance that is being migrated. This method changes the HTTP instance configuration to work with the Websphere Version 6.0 profile and makes the Websphere Version 4.0.x, 5.0.x, or 5.1.x instance no longer usable.

    Note: If a web server definition already exists in the Version 6 profile, migrating applications need to be manually mapped to the web server. This situation will occur in the following cases:

    • The Version 6 profile was created using the IBM Web Administration for iSeries, and either a new HTTP Server was created or an existing HTTP server was selected to be associated with the new Version 6 profile.
    • A web server definition was created for the Version 6 profile using the configureOs400WebServerDefinition script before migrating.

    Perform the following steps to map the migrated applications:

    1. Start the WebSphere Application Server administrative console.
    2. In the topology tree, expand Applications, and select Enterprise Applications.
    3. Select each Enterprise Application by selecting its name from the list.
    4. Select Map modules to servers from the Additional Properties menu.
    5. Select each module to be mapped by placing a check mark in the box in the Select column.
    6. While holding the Shift key, select both the application server and web server entries in the Clusters and Servers select box.
    7. Click Apply. Both servers should now show in the Server column next to each selected module.
    8. Click OK to complete the procedure.

  2. Configure the virtual host for the Version 6.0 profile.
    This step ensures that both the host and HTTP transport port number exist in the virtual host list.

    Note: If you created a new HTTP server in the previous step, or if you used the -portBlock parameter when performing the migration, the virtual host will not contain the correct port for communication with your HTTP server. You need to add a Host Alias for the port used by your HTTP server.

  3. Communicating with Web servers.
    This step regenerates the plug-in configuration file, plugin-cfg.xml. This step needs to be done after any configuration changes have been made. Additional configuration is required if Secure Sockets Layer (SSL) is enabled on a plug-in transport. In addition to copying the .kdb file to the Version 6.0 profile, edit the plug-in to specify the .kdb file required for the plug-in to use the transport. For more information on copying the .kbd files to the Version 6.0 profile, see J2EE security on the Migration configuration mapping page. For more information on editing the plug-in, see Configuring the Web server plug-in for Secure Sockets Layer.

Migrate the default file and directory authorities
The default for files and directories created by a WebSphere Application Server Version 4 application server is to have *PUBLIC authority set to *RX. The default for files and directories created by a WebSphere Application Server Version 5 application server is to have *PUBLIC authority set to *EXCLUDE. This default was changed in WebSphere Application Server Version 5.1 and Version 6.0 for security reasons. Two system properties can be added to change this WebSphere Application Server Version 6.0 default to the default that was used in WebSphere Application Server Version 4. The following instructions describe how to add these two system properties to an application server:

  1. Open the administrative console.
  2. Expand Servers and click Application Servers.
  3. Click the name of the application server for which you would like to add the system properties.
  4. Click Process Definition.
  5. Click Java Virtual Machine.
  6. Click Custom Properties.
  7. Click New.
  8. Specify os400.file.create.auth for the property name and RX and the property value.
  9. Click Apply.
  10. Repeat steps 7-9 for the os400.dir.create.auth property name and RX property value.
  11. Save your changes.
  12. Restart the application server for the changes to take effect.

Additionally, the grtwasaut script located in the /QIBM/ProdData/WebSphere/AppServer/V6/edition/bin directory can be used to explicitly grant authority to the appropriate users and authorization lists for directories and files in an profile. This is an alternative to the approach described above in that grtwasaut allows fine grained file and directory permissions to be defined. See The grtwasaut script for more information on using the grtwasaut script to change the file and directory authorities.

Change the ConnectionIOTimeOut properties for the Web container

Peformance changes to the WebSphere HTTP plug-ins may result in InterruptedIOTimeout exceptions while reading large requests, such as receiving file uploads to a servlet. Increase the ConnectionIOTimeout value in the Web Container of your application as follows:

  1. In the topology tree, expand Servers and click Application Servers.
  2. On the Application Servers page, click the name of the server that you want to modify.
  3. On the server's detail page, expand Web Container Settings, and click Web Container.
  4. On the Web Container page, click HTTP Transports.
  5. On the HTTP Transports page, click the transport that you want to modify.
  6. Click Custom properties.
  7. Click New and add a property named ConnectionIOTimeout. Set the property to the maximum time a servlet or JSP waits for a client to transmit request data.

  8. After you add a virtual host alias, restart the application server. See Start and stop application servers for more information.