Which WebSphere Application Server fix pack levels will my iFix install on?
sdittmar 110000FFY4 Comment (1) Visits (11008)
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:
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.
Here's an example of the entire property and it's value from a SDK iFix for WebSphere Application Server on z/OS:
In this example, it describes an iFix that can be installed on WebSphere Application Server on z/OS V8.5.0 through V184.108.40.206, as well as on WebSphere Application Server DMZ on z/OS V8.5.0 through V220.127.116.11. 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:
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 V18.104.22.168:
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.
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:
When the iFix is built, we know 22.214.171.124 won't include PIxxxxx, but we also can't be certain that 126.96.36.199 or 188.8.131.52 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 184.108.40.206 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 220.127.116.11 through 18.104.22.168 (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 22.214.171.124 level, but will need it re-built if they want to upgrade to 126.96.36.199 when it becomes available and still need the fix. When they upgrade to 188.8.131.52, the iFix will no longer be needed.
In the second scenario, assume:
In this case, we'd prefer to see you upgrade to the already-available 184.108.40.206 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 220.127.116.11 is already available, 18.104.22.168 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 22.214.171.124 through 126.96.36.199 without being rebuilt (which would look like [8.5.0,8.5.5.003) in the repository.xml). So they can upgrade from 188.8.131.52 to 184.108.40.206 and re-use the same iFix. When they upgrade to 220.127.116.11, the iFix will no longer be needed.