Which WebSphere Application Server fix pack levels will my iFix install on?

Body

The common question

I've been asked multiple times through various means, "How can I tell if my iFix is installable as-is when I upgrade WebSphere Application Server (WAS) to a newer fix pack level?" The answer, as it is to so many things, is "it depends." The manual method is not necessarily difficult, but may be a bit tedious if you have a lot of iFixes to consider. The automatic method is sometimes simpler and can be performed through the Installation Manager (IM) GUI or command line tool, depending on which options are offered for your platform.

You don't need to look inside every iFix

First it's useful to understand that there are some iFixes you can rule out without interrogating their meta-data or running a tool. Specifically:

• If the iFix is for an APAR that was delivered in any of the fix packs between your current level and your target level, you'll pick up the fix inherently and don't need an iFix at all. Likewise for the Java™ SDK, if the WAS fix pack contains a Java SDK SR and that SR contains your APAR, then you won't need an iFix.
  
  [Stay tuned, I plan to write a future article about how to figure out which WAS fix pack or Java SR contains a given APAR!]
• 
  
• On the other hand, if the iFix was for an issue with the WebSphere Java 6 SDK, you can almost always assume you *will* need to request a new iFix. This is because we deliver a different Java 6 SDK with almost every one of our WAS fix packs, so you will rarely want to install the same SDK iFix on a new WAS level even if the iFix packaging technically says it can be. Reinstalling a Java SDK iFix at the new WAS level when the SDK was also updated by the WAS upgrade may cause problems because Java 6 SDK iFixes for WAS are full replacements of the entire Java package. So, installing the iFix at the new WAS level would re-install the individual fix(es) *and* the previous SDK level from your old WAS level. This means you would be missing many other Java SDK fixes that were included in the newer SDK that we delivered with the new WAS level.

Take note that the above statements about the SDK are only in regards to the Java 6 SDKs that we deliver bundled inside of the WebSphere fix packs. Unlike the Java 6 SDK, Java 7 and 7.1 SDKs are maintained independently from the WAS maintenance. As a result, you only need to consider the need for a new Java 7 or 7.1 SDK iFix if you are upgrading the Java 7 or 7.1 SDK. If you are only upgrading WAS you can continue to run on the same Java 7 or 7.1 SDK if you want.

The Manual Method

The manual method requires inspection of each of your iFixes' meta-data.

1. Locate the repository.xml file in the root directory of the iFix archive
2. Extract and browse the repository.xml file
3. Find the value string within the property named applicable.offerings
4. Within that value string, identify the offering that relates to the product you are installing it on like "com.ibm.websphere.zOS.v85" is the offering name for WebSphere Application Server for z/OS V8.5
5. Immediately following the offering name you'll find the applicable releases indicated using interval notation

Here's an example of the entire property and it's value from a SDK iFix for WebSphere Application Server on z/OS:
<property name='applicable.offerings' value='com.ibm.websphere.zOS.v85 [8.5.0,8.5.5003);com.ibm.websphere.NDDMZ.zOS.v85 [8.5.0,8.5.5003)'/>

In this example, it describes an iFix that can be installed on WebSphere Application Server on z/OS V8.5.0 through V8.5.5.2, as well as on WebSphere Application Server DMZ on z/OS V8.5.0 through V8.5.5.2. Per standard interval notation, the '[' denotes that the set of applicable fix pack levels includes the left endpoint of the range, while the ')' denotes that it excludes the right endpoint of the range.

The Automatic GUI Method

The automatic GUI method requires you to begin going through the upgrade process even though you may not yet actually begin the upgrade. Also, this method is only available on the platforms that have a GUI implementation of IM. So, for example, it is not available to WAS on z/OS. But for those with a GUI, it's as simple as following the upgrade steps through the GUI right up to the last step (in other words, you don't need to actually begin the upgrade). The output in the GUI should identify which of your current iFixes will and will not be reinstalled after the upgrade, and why.

You can expect to see a message identifying any iFixes that:

• will be reinstalled because they are still needed and can be installed as-is on the new fix pack level
• won't be reinstalled because the APAR they represent was delivered in the new fix pack(s) you are installing
• won't be reinstalled because they were not built for your new pack level

The Automatic Command Line Tool Method

The IM command line tool's executable file is called imcl and is documented in the Installation Manager section Command-line arguments for the imcl command.

But, here's a quick overview of how you would use the command line tool to find out if your current iFixes are applicable to your target level. In this example we'll assume you're planning to upgrade to WebSphere Application Server on z/OS V8.5.5.1:

1. First, figure out the internal version name of the fix pack you're upgrading to. You can query the IBM WebSphere Live Service repository using the imcl command. For example:
   
   InstallationManager/eclipse/tools/imcl listAvailablePackages -repositories http://www.ibm.com/software/repositorymanager/com.ibm.websphere.zOS.v85 -prompt
    
   • If you do not have access to the IBM WebSphere Live Service repository from your servers you can replace the repository's argument with a local repository containing the fix pack level you are inquiring about
   • If you're using the IBM WebSphere Live Service repository, it will prompt you for your IBM ID and password
   • Here is a sample output for this command:
     
     com.ibm.websphere.NDDMZ.zOS.v85_8.5.1.20121017_1748
     com.ibm.websphere.NDDMZ.zOS.v85_8.5.2.20130327_1857
     com.ibm.websphere.NDDMZ.zOS.v85_8.5.5000.20130514_1111
     com.ibm.websphere.NDDMZ.zOS.v85_8.5.5001.20131018_2325
     com.ibm.websphere.NDDMZ.zOS.v85_8.5.5002.20140408_2032
     com.ibm.websphere.NDDMZ.zOS.v85_8.5.5003.20140730_1355
     com.ibm.websphere.zOS.v85_8.5.1.20121017_1748
     com.ibm.websphere.zOS.v85_8.5.2.20130327_1857
     com.ibm.websphere.zOS.v85_8.5.5000.20130514_1111
     com.ibm.websphere.zOS.v85_8.5.5001.20131018_2325
     com.ibm.websphere.zOS.v85_8.5.5002.20140408_2032
     com.ibm.websphere.zOS.v85_8.5.5003.20140730_1355
2. 
   
3. Identify which iFixes are applicable to the fix pack level you are upgrading to. For example, use the imcl command to list all applicable iFixes for version 8.5.5.1:
   
   InstallationManager/eclipse/tools/imcl listAvailableFixes com.ibm.websphere.zOS.v85_8.5.5001.20131018_2325 -repositories [repository_path(s)_to_your_iFixes] -prompt
    
   • You can include multiple iFixes/repositories in a single command by making a comma-separated list in the repositories argument
   • If any applicable fixes are found they will be listed in the output, otherwise you will see no output
   • You can include the IBM WebSphere Live Service repository URL in the repository list if you want to see what published iFixes are available as well

What does the fix pack level at the front of the iFix file name indicate?

The fix pack level that is a part of an iFix's filename indicates the earliest fix pack level that the iFix is applicable to. You need to check the repository.xml or use the IM tools as described earlier if you want to identify the upper limit to the range of fix packs it can be installed on. So if the iFix file were named 8.5.0.0-WS-WASJavaSDK-OS390-IFPIxxxxx.zip, it would be applicable as far back as 8.5.0.0.

How do I get new versions of the iFixes I need that won't install on my new level as-is?

If your iFix was published to the IBM Fix Central repository, you may find an updated applicable version via the IM GUI or command line tool. If you received your iFix through a PMR and it wasn't published and you need it rebuilt for your new fix pack level, simply open an SR or PMR to your friendly IBM WebSphere Support team and they will be happy to work with the relevant developers.

Why aren't iFixes built to be installable on every fix pack affected by the defect by default?

The short answer is simply that we cannot build an iFix and assume it will safely install on a future fix pack level that has not yet been released, because we can't be certain that those future fix packs won't introduce other changes to the same files as the given iFix, which means we could inadvertently back level such a future fix. They also tend to be built for a fix pack level range starting at the level of the client requesting it and ending at either the first available fix pack containing changes to one of the same classes, or through the most recent available fix pack level if there have not been any changes in those classes since the client's level.

To try to explain that a little better, there are essentially two scenarios... an iFix is requested before the APAR is available in a fix pack, or after the APAR is available in a fix pack. For the first scenario, assume:

• APAR PIxxxxx fixes a defect in WAS V8.5.0.0
• The fix will be delivered in fix pack 8.5.5.3
• Before 8.5.5.2 is released, we get a request for an iFix of PIxxxxx on 8.5.5.1

When the iFix is built, we know 8.5.5.2 won't include PIxxxxx, but we also can't be certain that 8.5.5.2 or 8.5.5.3 won't ship another APAR that alters one of the same files as PIxxxxx. If we build the iFix claiming that it can install on 8.5.5.2 it would allow the customer to fix PIxxxxx on that level, but it might inadvertently back level a file and break another APAR's fix. So, in this scenario the iFix would be built to install on 8.5.0.0 through 8.5.5.1 (which would look like [8.5.0,8.5.5.002) in the repository.xml). The customer will be able to apply this on their current 8.5.5.1 level, but will need it re-built if they want to upgrade to 8.5.5.2 when it becomes available and still need the fix. When they upgrade to 8.5.5.3, the iFix will no longer be needed.

In the second scenario, assume:

• APAR PIyyyyy fixes a defect in WAS V8.5.0.0
• The fix was delivered in 8.5.5.3
• After 8.5.5.3 is released, we get a request for an iFix of PIyyyyy on 8.5.5.1

In this case, we'd prefer to see you upgrade to the already-available 8.5.5.3 fix pack level for the fix. But, assuming this was for situation that precludes you from upgrading anytime soon, we would do our best to oblige. Since 8.5.5.3 is already available, 8.5.5.2 would be as well meaning we could safely build the fix while knowing exactly what, if any, other APARs affected the files PIyyyyy needs to change in each of the affected releases. That allows us to build it to install on 8.5.0.0 through 8.5.5.2 without being rebuilt (which would look like [8.5.0,8.5.5.003) in the repository.xml). So they can upgrade from 8.5.5.1 to 8.5.5.2 and re-use the same iFix. When they upgrade to 8.5.5.3, the iFix will no longer be needed.

Steve Dittmar
WAS for z/OS L2 Support

title image (modified) credit: (cc) Some rights reserved by sixsixfive