Before you begin
Determine whether you have an existing version of WebSphere Application Server installed on the machine where you plan to install your Version 5 product.Why and when to perform this task
To migrate from Version 4.0.1 applications and configurations to Version 5, follow this procedure:
Steps for this task
If your existing configuration makes use of a non-390 Web server and associated AE plug-in, you should review the required Web server levels and update as appropriate. Refer to IBM WebSphere Application Server supported hardware, software, and APIs for current requirements.
Functional dependencies on the 390 infrastructure have changed. See Prerequisites needed for WebSphere Application Server for z/OS comparing Version 3.5 SE, Version 4.0.1, Version 5.0, and Version 5 prerequisites.
Version 4.0.1 must be at minimum service level W401501 to coexistence with Version 5.
See Migrating and coexisting for more information.
Installation instructions have been provided with your ServerPac or PDO order.
Note that the Version 5 default /install root directory on z/OS is WebSphere/V5R0M0/AppServer, and it does not conflict with mount points or directory structure of the existing Version 4.0.1 release.
With the introduction of Version 5, significant changes to Admin, system structure, etc. were introduced. For this reason, it is always recommended the new samples are run to experience the environment.. See Samples Gallery for more information.
Version 5 requires the use of the HTTP transport, and HTTP listening ports must be selected so as to not conflict with the existing Version 4.0.1 configuration.
Prerequisites levels needed for WebSphere Application Server for z/OS may have changed from Version 4.0.1. Review these prerequisites at Prerequisites needed for WebSphere Application Server for z/OS.
Most Version 4.0.1 applications will continue to run in the new servers. However, applications generated in WSAD 4.0 and WSAD IE 4.1.1 are not formally supported for deployment into Version 5 runtimes. Formal support necessitates movement of the application to Version 5 level tooling. In the case of WSAD 5.1, this tool has the flexibility to generate both J2EE 1.2 and J2EE 1.3 applications allowing convergence to a single tool to support Version 4.0.1 and Version 5. In the case of WSAD IE 5.1, there are conflicts in tooling jars with WSAD IE 4.1.1. Customers will need to maintain both tooling levels until they have migrated everything to the latest levels.
The Class API checker tool can be used to analyze servlets and EJBs to determine if any APIs are unsupported or deprecated. The CACT tool can be found at WebSphere Developer Domain downloadable tools. If required changes are found, it will be necessary to modify them and then install into the Version 5 servers. If changes are not required, then the migration utility can be utilized.
Key things to note that may cause a need for application changes include the following:
Even though the Java language allows programmers to explicitly specify the encoding of a file that is to be opened and read by the JVM, many programmers do not take advantage of this capability and rely on the default encoding. If you have applications which access EBCDIC encoded files, you must ensure that they explicitly specify this encoding in the application code, or you must change the encoding of the target file to match this new JVM setting.
This utility is being provided as an option on 390fy. In Version 4.0.1 it was required that EARs be processed through the 390 AAT or 390fy to condition them for deployment into Version 4.0.1. In Version 5, and higher, this conditioning is not required. This utility will remove the conditioning that was done for existing Version 4.0.1 EARs that are being migrated. It should be noted that if the application is being sent back through the WSAD 5.0, or later version tooling, that the resulting EAR is ready for installation into Version 5 and that the use of migration utility is not required. Support for migrating Version 4.0.1 applications to Version 5 has been shipped in Version 4.0.1 service (W401502). This support has been provided as a new -v5mp option for the 390fy tool. See Utilizing WebSphere administrative capabilities to support migration from V4.0.1 for more information.
For Web applications being migrated from Version 4.0.1 the following should be noted. In Version 4.0.1, the classes generated from JSP files are in a package based on the directory structure of the WAR. Any JSP at the top of the context root is in the unnamed package, and JSP files in subdirectories of the root are in packages named after the subdirectories. In Version 5, and higher, the classes generated from JSP files are all in the package org.apache.jsp. Therefore, the classfiles are not compatible between versions. When migrating an enterprise application from Version 4.0.1 to Version 5, the JSP files need to be recompiled so that the classfiles are regenerated into the correct packages. Use the -preCompileJSPs option of wsadmin tool during the installation of the application to force this recompiling.
Most Version 4.0.1 configurations will include a Web server. This can be a 390 Web server or any Web server supported by Version 4.0.1 AE. If a Web server configuration is required, then the Web server to be used must be updated to the Version 5 prerequisite level and the appropriate plug-in must be installed. It should be noted that the Version 5 plug-in can support both Version 4.0.1 and Version 5 application servers. With this in mind, several migration configurations are possible:
See Migrating security configurations from WebSphere Application Server Version 4.0.1 for more information.
What to do next
Migration from Version 4.0.1 to Version 5 does not require extensive tuning.
Migration from Version 3.5 SE to Version 5 does require you to examine the migrating applications.
After planning for migration and coexistence, you are ready to continue the installation.