Before you begin
This task uses IBM functions and methods to migrate WebSphere Application Server for z/OS in a sysplex from one functional level to the next, with as little disruption as possible. This task does not apply to WebSphere Application Server for z/OS running in a monoplex, or on a single system in a sysplex. Installing a new code level in a monoplex requires you to shut down WebSphere Application Server for z/OS. You have no choice but to disrupt service to clients of the monoplex system. You can also ignore this topic if disrupting service to clients is not a problem when running WebSphere Application Server for z/OS in a sysplex.
Why and when to perform this task
IBM functions and methods for migrating WebSphere Application Server for z/OS include the following:
You can install new functional levels of WebSphere Application Server for z/OS without disrupting service to your clients, provided you have the proper HFS structure in a sysplex and you use what is defined here as a rolling upgrade. The rolling upgrade method upgrades the host cluster of WebSphere Application Server for z/OS by upgrading clustered host instances one at a time. This lets you keep available service to clients while you do the upgrade. Availability of service continues because only one system is removed from the host cluster at any time, while other clustered host instances remain running.
Tip: If you configure your Network Deployment environment using the default value for the product HFS path in the Customization Dialog, it will result in all the nodes pointing directly at the mount point of the product HFS. This makes rolling maintenance in a nondisruptive manner almost impossible. If a cell is configured in this way, applying service to the product HFS affects all the nodes at the same time; and if multiple cells are configured in this way, applying service to the product HFS affects all the cells at the same time. You might want to specify what is referred to as an "intermediate symbolic link" between each node's configuration HFS and the actual mount point of the product HFS. This strategy is described in the WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance white paper. See the Washington Systems Center Sample WebSphere for z/OS ND Configuration white paper for more information about this issue and its relationship to applying maintenance. See the WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links instructions for information on obtaining and using a utility that would allow you to update an existing configuration HFS to use intermediate symbolic links.
You have the option of using either of two methods for performing the rolling upgrade. The optional methods differ in the HFS structure they use. One method uses a version-specific HFS structure. The other uses an alternate HFS structure. Read through the procedure for using each method to determine which is better for you. The main determinant is whether to use a shared HFS.
Steps for this task
Results
You can maintain service to clients when upgrading the host cluster of WebSphere Application Server for z/OS.