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:
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/db2The HFS structure appears in the following illustration:
You can use a symbolic link to determine which code version any system in the sysplex addresses:
/usr --> $VERSION/usrYou 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
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.