Using a version-specific HFS structure to upgrade WebSphere Application Server for z/OS

Before you begin

This task describes one of the two methods for performing a rolling upgrade of WebSphere Application Server for z/OS in a sysplex that is introduced by Installing new releases and maintenance levels of WebSphere Application Server for z/OS. This task describes using a version-specific HFS structure to upgrade WebSphere Application Server for z/OS.

Why and when to perform this task

Using a version-specific HFS structure in a rolling upgrade means that two different versions of WebSphere Application Server for z/OS run in the sysplex at the same time, each with a separate HFS structure. A conventional sysplex environment has but one HFS structure that all WebSphere Application Server for z/OS systems share. To run a second, different version of WebSphere Application Server for z/OS at the same time requires a second HFS structure that is specifically for the second version as shown in the following illustration:

HFS structure for the rolling upgrade method

Each version-specific HFS structure requires its own /usr directory (containing a version-specific level of WebSphere Application Server for z/OS and Java) and /db2 directory (containing a version-specific level of JDBC) because of code-level interdependencies between products.

With the dual HFS structure in place, you can mount one code-level version of WebSphere Application Server for z/OS, run the host cluster from that mount point, and upgrade a second mount point where you mounted the other version of WebSphere Application Server for z/OS.

Example: Assume you mount a version-specific HFS for one service level (PTF 10) at /VersionA and another version-specific HFS for another service level (PTF 15) at /VersionB:

mount omvs.ptf10.was.hfs  at /VersionA/usr/lpp/WebSphere
mount omvs.ptf10.java.hfs at /VersionA/usr/lpp/java/IBM
mount omvs.ptf15.was.hfs  at /VersionB/usr/lpp/WebSphere
mount omvs.ptf15.java.hfs at /VersionB/usr/lpp/java/IBM
mount omvs.ptf15.jdbc.hfs at /VersionB/usr/lpp/db2
The HFS structure appears in the following illustration:

Mount point configuration for WebSphere Application Server for z/OS

You can use a symbolic link to determine which code version any system in the sysplex addresses:

/usr --> $VERSION/usr
You use the SETOMVS command to control how $VERSION resolves. In this example, set the initial value of $VERSION for each system in the sysplex to VersionA. All systems that use the symbolic link to refer to the /usr directory resolve to /VersionA/usr.

For any system in the sysplex to use the HFS structure associated with PTF15, change the value of $VERSION on that system (and only on that system) to VersionB. Accordingly, any references on that system to /usr resolve to /VersionB/usr through the symbolic link.

Use the following procedure to switch the code level for a clustered host instance:

Steps for this task

  1. Install the new code, copy it to a new data set, and mount the data set at the VersionB mount point.
  2. Shut down all Application Servers and WebSphere Application Server for z/OS on that clustered host instance
  3. Use the SETOMVS command to change $VERSION to VersionB
  4. Using SET PROG, load the LPA modules from data sets associated with the new level
  5. Change the start procedures to address the new code level load libraries
  6. Restart WebSphere Application Server for z/OS and the Application Servers.
  7. Repeat the prior steps of this process for each clustered host instance, one at a time, to upgrade the code level of WebSphere Application Server for z/OS throughout the sysplex without disrupting service to your clients.

Results

Each code level of WebSphere Application Server for z/OS is designed to tolerate an older code level. Differing levels of WebSphere Application Server for z/OS can coexist compatibly within the sysplex during the upgrade process.

In cases when a new level of WebSphere Application Server for z/OS introduces new functions, all members of the host cluster run in compatibility mode during the upgrade process. When all clustered host instances are at the new code level, restart each instance, one by one, to enable the new function.

What to do next

Read about Using an alternate HFS structure to upgrade WebSphere Application Server for z/OS.

Related tasks
Using an alternate HFS structure to upgrade WebSphere Application Server for z/OS



Searchable topic ID:   tins_dualhfsov
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/tins_dualhfsov.html

Library | Support | Terms of Use | Feedback