Some customers have been running into a problem when adding patches and fixes to their 8.0 WebSphere environments. The most common issue exists within existing environments that were not originally installed with Rational Automation Framework.
When installing WebSphere with IBM Installation Manager, depending on whether you do it silently or via the GUI. The agent dataLocation is set behind the scenes with a default. This default value, can be seen in the following locations (depending on if you are using Windows or Linux/Unix. I will explain using Windows in this example. Same as for Linux with variations to file paths.
Windows (C:\Program Files (x86)\IBM\Installation Manager\eclipse\configuration) -- Config.ini---
cic.appDataLocation=C\:\\ProgramData\\IBM\\Installation Manager --- Agent Data Default Location ---
This can be changed after an installation of WebSphere has been installed. So the data location may be different.
AGENT DATA LOCATION
The agent data location is used to store files such as Eclipse p2 repositories and installed.xsd/xsl and installRegistry.xml. These files are important for IM to recognize what you already have installed on your system. What version of WAS and keep track of patches and fixes that have been added.
The issue with RAF is that it launches the IBM Installation Manager using imcl and passes an argument called -dataLocation to the Installation Manager. Since RAF uses a different dataLocation than the IM default. There will be no record of WAS already being installed. This is different than if you had installed WAS with RAF. RAF would have set that dataLocation to the RAF default dataLocation on the install. Thus removing this issue during updates and fixes.
I do not recommend trying to change the ANT tasks. Although, it can be done. You can change the ANT task and remove the flag from being passed. I wont talk about this hear because unless you remember you did that. It could hinder future installs of WAS with RAF. Since RAF is intended to be an all or nothing product. At least in my opinion.
The best way to work around this issue, is to play with the response file. There are many ways to get a working response file. Which leads me into the second part of the issue when updating and applying fixes with RAF.
When installing WAS with RAF. RAF It passes in an offering ID and profile ID that are the same. So when it comes time to update, the ID's match. When installing WAS without RAF. Installation Manager creates the profile ID and offering ID which are different than what RAF would use. RAF my see what you have installed, but if the ID's do not match. It will either fail or attempt to install the "new product" because the ID's do not exist in the agent dataLocation.
The installation process works like this.
1. Checks the media tree location for disk1/disk.inf. (You can get away with just putting the disk.inf in the media tree location and nothing else. If this is an existing installation there is no need to have the full media for you are not installing anything.)
2. Checks to see if IM is installed. (Keep in mind, you must have the exact same IM media on your RAF server as you have installed on the target system. If you do not, it will install IM again with the different version. This you do not want. You can also not get away without having the IM media in the RAF media tree.)
3. If already installed, it checks to see if updates are needed. It will either update or not.
4. It then creates the response file and will install the fixes / patches. (As long as you have the PATCHES= or (portal) FIXES= etc. (You can find more on those values in the RAF IBM Infocenter)
The most least invasive way to fix the issue noted in this blog is to get your own response file and place it on the framework server. The easiest way is to start IM from the command line, passing in the -record and -skipInstall parameters. This will allow you to build a response file. The only thing to note would be the repository location being used.
-record and -skipinstall can be found in the IBM InfoCenter for the version of Installation Manager that you have.
Once you have a working response file. Put that response file on the framework server and use it to run your updates or fixes. The location on the framework server is as follows.
NOTE: If you have tried and failed previously. There will be a response file at the location below. You can open it up and place the new response file text there.
If you have not attempted this yet. The location below:
Will contain the templates used with the locations set as variables that are passed into the script before it is copied into the work directory location above.
Sometimes it is easiest to just run it once, let it fail, and use that response file. Since changing the template response file can be more dangerous for later installs updates etc.
You can then use this response file to do all of your updates to an existing environment for the future, until this issue has been fixed.
This can get really complicated. So I would encourage individuals using Portal and WAS to contact support with further issues. The easiest way to work with Portal updates is via the FIXES. There is a direct fix action that can be ran quickly. This is a "hidden" action because it can not be seen from the eclipse UI or the rafw.bat/sh CLI using -d or -p. It's a portion of the ANT task that is involved with installations. Thus it one of the actions called by the composite install action. I wont go into this here unless there is general interest. I do not work with many Portal customers.