Before you begin
This task is the second 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. Using a version-specific HFS structure to upgrade WebSphere Application Server for z/OS describes the first method. This task describes using an alternate HFS structure to upgrade WebSphere Application Server for z/OS.
Why and when to perform this task
The alternate HFS structure accomplishes the same objective as the version-specific HFS structure, but does not mount a product HFS directly off the version-specific subdirectories (referred to by the $VERSION symbolic link). Rather, version-specific subdirectories refer to system-specific subdirectories using symbolic links with the $SYSNAME symbol. In turn, system-specific subdirectories refer to program product subdirectories through symbolic links. The alternate HFS structure is depicted in the following illustration:
The alternate HFS structure has the following characteristics:
The WebSphere Application Server for z/OS, Java, and DB2 for OS/390 (JDBC) subdirectories do not contain product code but instead, contain symbolic links to system-specific subdirectories through the use of the $SYSNAME symbol. As far as WebSphere Application Server for z/OS is concerned, you need not change these symbolic links. However, you should plan for creating version-specific structures for future system upgrades.
The symbolic links point to specific code levels (for example, WebSphere/PTFx). To change the code level that a system uses, you change these symbolic links.
Each of these subdirectories can have one or more subdirectories for a specific code level.
With the alternate HFS structure in place, you can mount one or more code levels of WebSphere Application Server for z/OS, Java, or DB2 for OS/390 (JDBC) under their individual component subdirectories. Each system-specific subdirectory uses symbolic links to component code levels and can refer to new code levels by changing those symbolic links.
There are certain advantages to the alternate HFS structure:
Example: Assume you have an individual component directory for WebSphere Application Server for z/OS (/WebSphere), Java (/Java), and DB2 for OS/390 (JDBC) (/DB2). Assume that each directory contains two subdirectories, one for PTFx (/PTFx) and one for PTFy (PTFy). Also assume that the code for each component update is in its own HFS data set, such as OMVS.PTFX.WEB.HFS, OMVS.PTFX.JAVA.HFS, and OMVS.PTFX.JDBC.HFS, for example. The mount commands are:
MOUNT FILESYSTEM('OMVS.PTFX.WEB.HFS') MOUNTPOINT('/WebSphere/PTFx') TYPE(HFS) MODE(RDWR) MOUNT FILESYSTEM('OMVS.PTFX.JAVA.HFS') MOUNTPOINT('/Java/PTFx') TYPE(HFS) MODE(RDWR) MOUNT FILESYSTEM('OMVS.PTFX.JDBC.HFS') MOUNTPOINT('/DB2/PTFx') TYPE(HFS) MODE(RDWR) MOUNT FILESYSTEM('OMVS.PTFY.WEB.HFS') MOUNTPOINT('/WebSphere/PTFy') TYPE(HFS) MODE(RDWR) MOUNT FILESYSTEM('OMVS.PTFY.JAVA.HFS') MOUNTPOINT('/Java/PTFy') TYPE(HFS) MODE(RDWR) MOUNT FILESYSTEM('OMVS.PTFY.JDBC.HFS') MOUNTPOINT('/DB2/PTFy') TYPE(HFS) MODE(RDWR)
System SYS1 refers to the PTFx levels of code through these symbolic links:
/WebSphere --> /WebSphere/PTFx /Java --> /Java/PTFx /DB2 --> /DB2/PTFx
If you want system SYS1 in the sysplex to use the HFS structure associated with PTFy, change the symbolic links for /WebSphere, /Java, and /DB2:
/WebSphere --> /WebSphere/PTFy /Java --> /Java/PTFy /DB2 --> /DB2/PTFy
Use the following procedure to switch the code level for the WebSphere Application Server for z/OS for the clustered host instance on SYS1.
Steps for this task
Results
By repeating this process for each clustered host instance, one at a time, you can upgrade the code level of WebSphere Application Server for z/OS throughout the sysplex without disrupting service to your clients.What to do next