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.

Change and install a new EJB dbschema database name
If the EJB dbschema name was hard coded to database EJB in your Version 3.5 application, change and install a new EJB dbschema database. For more information, see Change and install a new EJB dbschema database name in the Application development topic.

Change the HTTP transport after migration
If the -portBlock parameter was not specified in the WASPostUpgrade script, you need to use the Version 5 administrative console to adjust the ports manually after migration has completed."

  1. Use the Version 5 administrative console to change the HTTP transport port:
    1. Navigate to Servers --> Application Servers --> my_server where my_server is the name of the application server that was migrated.
    2. Click Web Container.
    3. Click HTTP transports.
    4. Click on a host.
    5. Adjust the Port property by entering a port not currently in use on your iSeries server. Record both the old and new port numbers; they are needed for step 2.
    6. Click OK.
    7. Repeat for each host.
  2. Adjust your Virtual hosts to correspond to your HTTP transport.
    1. Click Environment --> Virtual Hosts.
    2. Select your virtual host.
    3. Click Host Aliases.
    4. Click New.
    5. Select one of the ports that were changed in step 1.
    6. Enter the port that this was changed to in step 1.
    7. Click OK.
    8. Repeat for each port that was changed in step 1.

  3. Click Save.
  4. Regenerate your plugin configuration.
    1. Navigate to Environment --> Update Web Server Plugin.
    2. Click OK.

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 for security reasons. Two system properties can be added to change this WebSphere Application Server Version 5 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/WebAS5/base/bin directory can be used to explicitly grant authority to the appropriate users and authorization lists for directories and files in an instance. 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 in the Administration topic for more information on using the grtwasaut script to change the file and directory authorities.

Migrate the web server plug-in
If the WebSphere Application Server Version 3.5.x plug-in for your web server uses Open Servlet Engine (OSE) transport, switch to HTTP transport when migrating to WebSphere Application Server Version 5.

The following instructions are specific to the Web server being supported and assume that you can successfully migrate existing Web applications:

Plug-in migration has been tested with the following Web server products:

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 5 instance. This method allows both Websphere Version 3.5.x or 4.0.x and Version 5 instances to continue operating correctly.

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

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

  3. Regenerate 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 5 instance, 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 5 instance, see J2EE security on the Migration configuration mapping page. For more information on editing the plug-in, see Step 5: Configure HTTPS transport for the Web container of the Configure SSL for WebSphere Application Server in the Security topic.

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, 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 in the Administration topic for more information.