Update Installer for WAS V6.0
Overview
This topic describes how to use the IBM Update Installer for WebSphere Software to install interim fixes, fix packs, and refresh packs.
Use the update installer program as the root user on a Linux or UNIX platform, or as the administrator on a Windows platform.
The Update Installer wizard is an InstallShield for Multiplatforms wizard that runs with either a graphical user interface or in silent mode with or without a response file. When you omit the response file in silent mode, the wizard installs the last maintenance package that you downloaded to the default maintenance directory.
The following procedure shows the high-level steps involved in installing a maintenance package:
- Back up and delete the updateinstaller directory of the existing update installer.
- Download the most current version of the update installer, fix pack, or refresh pack ZIP or TAR file from the Support site into the install_root directory.
- Unpack the ZIP or TAR file that you downloaded to create the updateinstaller directory and several subdirectories, including the maintenance directory.
- Interim fix only: Download the interim fix from the Support Web site into the maintenance directory.
- Use the update installer to install the interim fix, fix pack, or refresh pack. The update installer creates a backup file in...
install_root/properties/version/update/backup
IBM does not support user modifications to backup files.
The update installer updates the core product files in a WAS product. Service in a maintenance package might update the following core product files in the installation root directory:
- JAR files in the lib directory
- The SDK, Java technology edition, in the java/jre directory
- Scripts in the bin directory
- Profile templates
Some maintenance packages provide required service for existing profiles in addition to service for the core product files. Each maintenance package that has profile maintenance provides a script that we can use to change profiles that might be inaccessible at the time you install the maintenance package. Each profile fix also includes a script to undo changes to existing profiles.
The update installer prompts you to back up your configuration when installing a maintenance package that has required maintenance for profiles.
Some maintenance packages provide optional service for existing profiles. If a maintenance package contains optional service for existing profiles, the readme file for the maintenance package describes how to install or remove the service.
Use the backupConfig command to back up the configuration of each profile that the maintenance package can update. Or archive...
install_root/profiles
...to back up all of the profiles at once.
If you uninstall a maintenance package, the update installer does not uninstall the maintenance package from profiles. The reason for not removing the maintenance is that you might have configured the profile after installing the maintenance. To restore an original profile, use the restoreConfig command or copy the profile from the archived profiles directory to replace the changed profile.
Viewing the fix level of the node
Use...
install_root/bin/versionInfo
...to display the exact fix and version level of the product.
Do not use the versionInfo command while installing or uninstalling a maintenance package.
Updating cluster members
Apply the same maintenance packages to all of the WAS nodes in a cluster. When all of the cluster members are not at the same service level, the following exception can occur:
| DRSCacheApp E DRSW0008E:
Exception is: com.ibm.disthub.impl.jms.JMSWrappedException: {-1361012295|unknown|java.io.OptionalDataException|} |
This error can cause memory replication to function improperly.
Concurrent launch limitation
Do not launch multiple copies of the Update Installer wizard at one time.
Concurrent launches of the update installer program are not supported. Performing more than one update at the same time can produce unpredictable results, which might include a failed or faulty installation.
Gathering required information
The graphical interface requires the following information that supply:
| Field | Valid values | Description | |||
| File path of the installation root directory of the WAS product or another IBM product that the Update Installer can update.
Although the examples in this readme file describe WAS products, always install a maintenance package from the installation root directory of the product that you are updating. | Identify the installation root directory for one of the following products:
|
Changes to Update Installer
- Additional Update Installer support for 64 bit Solaris platform
Starting in V6.0.2.11, fix packs are now available for the following additional platform:- Solaris on x86 Intel EM64T/AMD - 64 bit
Update Installer for the AIX 64 bit platforms has also recently been added. Note that Update installer provided for "Linux for zSeries" can be used to install 31bit Fix Packs and 64 bit Fix Packs on the supported Linux on zSeries platforms. Update Installer for all platforms can be downloaded from the Update Installer for WebSphere Software IBM Web site.
- Solaris on x86 Intel EM64T/AMD - 64 bit
Known Issues
- UpdateInstaller incorrectly reports "SUCCESS":
A "success" message is displayed, although the UpdateInstaller has not actually take any action. This gives the false impression that the maintenance package has been applied when nothing has actually happened. If nothing has been updated, the maintenance package installation should have failed instead.
- Uninstall Issue:
During the uninstallation of refresh pack 6.0.2.0 or service pack 6.0.2.x, error message can be found in a file...
install_root\logs\run-iscddeploy.err
...indicating...
ws_ant.bat" not found (UNIX platform) OR
failure to create a ws_ant process (Windows platform).
*This message is benign, and can be ignored.*
Installing maintenance packages
The following procedure describes how to install a maintenance package.
- Log on as root on a Linux or UNIX operating system, or as a member of the administrator group on a Windows system.
For System i, log on as a user profile with *ALLOBJ special authority.
- Set umask to 022.
- Back up any files and subdirectories in...
install_root/updateinstaller
...if necessary.
- Delete...
install_root/updateinstaller/maintenance
...and all of its subdirectories.
- For refresh packs and fix packs only, download the fix pack or refresh pack ZIP file or TAR file from the Support site into a temporary directory.
- Download the latest version of the Update Installer for WebSphere Software as a ZIP file or a TAR file from the Update Installer for WebSphere Software IBM Web site.
- For interim fixes download the Update Installer from the Support site into a temporary directory.
Download the ZIP file or TAR file for the Update Installer for WebSphere Software from the Update Installer for WebSphere Software IBM Web site.
- Unpack the ZIP file or the TAR file.
- Unzipping a maintenance package ZIP file
- Open the ZIP file with your unzip utility, such as WinZip.
- Extract the contents to the appropriate installation root directory:
WAS product:
/usr/IBM/WebSphere/AppServer
Application Client:
/usr/IBM/WebSphere/AppClient
Web server plug-ins:
/usr/IBM/WebSphere/Plugins
IBM HTTP Server:
/usr/IBM HTTP Server
WAS Extended Deployment:
/usr/WebSphere/DeploymentManager
WAS Edge Components:
Not applicable. The downloads for Edge on Windows platforms are all ZIP files that contain a setup file. Edge downloads do not use the Update Installer. Run the setup file from the temporary download location and select where to install the full product.
- Open the ZIP file with your unzip utility, such as WinZip.
- Untarring a maintenance package TAR file
Change directories to the installation root directory of the product that you are updating: WebSphere Application Server products:
Untar the file into the product installation root directory:For example, use the following commands to untar a refresh pack file for a Linux system:
cd /opt/IBM/WebSphere/AppServer tar -xvf /tmp/downloads/6.0-WS-WAS-LinuxX64-RP0000002.tar
Application Client:
Untar the file into the installation root directory:
For example, use the following commands to untar a refresh pack file for a Linux system:
cd /opt/IBM/WebSphere/AppClient tar -xvf /tmp/downloads/6.0-WS-AppClient-LinuxX32-RP0000002.tar
Web server plug-ins:
Untar the file into the installation root directory:
- /usr/IBM/WebSphere/Plugins
- /opt/IBM/WebSphere/Plugins
For example, use the following commands to untar a refresh pack file for a Linux system:
cd /opt/IBM/WebSphere/Plugins tar -xvf /tmp/downloads/6.0-WS-WASPlugIn-LinuxX64-RP0000002.tar
IBM HTTP Server:
Untar the file into the installation root directory:
- /usr/IBMIHS/
- /opt/IBMIHS
For example, use the following commands to untar a refresh pack file for a Linux system:
cd /opt/IBMIHS tar -xvf /tmp/downloads/6.0-WS-WASIHS-LinuxIA64-RP0000002.tar
WebSphere Application Server Extended Deployment:
Untar the file into the installation root directory:
- /usr/WebSphere/DeploymentManager
- /opt/WebSphere/DeploymentManager
For example, use the following commands to untar a refresh pack file for a Linux system:
cd /opt/IBMIHS tar -xvf /tmp/downloads/<name_of_maintenance_file>.tar
WebSphere Application Server Edge Components:
Not applicable. The downloads for Edge on Windows platforms are all ZIP files that contain a setup file. Edge downloads do not use the Update Installer. Run the setup file from the temporary download location and select where to install the full product.Unpacking the maintenance file creates the following directory structure:
install_root /updateinstaller
/framework
/lib
/maintenance
/responsefiles
Version information is stored in the version.txt file in the updateinstaller directory. A new version might ship to correspond to any new fix. Information in the version.txt file is displayed prominently in the title bar of the wizard and is also recorded in the updatelog.txt file.Always download and use the latest version of the Update Installer wizard when installing an interim fix.
- Unzipping a maintenance package ZIP file
- Interim fixes only: Download the maintenance package *.pak file from the Support Web site into the maintenance directory.
Download maintenance packages for the Update Installer for WebSphere Software to install from the following IBM Web pages: - Download maintenance packages for IBM WebSphere Extended Deployment, Version 5.1 from the IBM Support site for IBM WebSphere Extended Deployment.
- Download maintenance packages for Version 6 of the WAS products from the IBM Support site for WebSphere Application Server.
Tip: Do not attempt to unzip or unpack the *.pak file.
- Use the Windows Services panel to stop all services for WAS processes.
- Stop all Java processes that use the IBM Software Developer Kit (SDK) that the WAS product provides.
Before installing or uninstalling interim fixes, fix packs, and refresh packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WAS provides. Stop all WebSphere Application Server-related Java processes that are running on the system where you are using the update installer program. For example, Java processes can include:
- All Java Virtual Machines (JVMs)
- WebSphere Application Server processes:
- Application server processes
- The nodeagent process on an application server node when the node is federated into a deployment manager cell
- The dmgr process for the deployment manager server
- IBM HTTP Server processes
- First steps consoles
- Installation verification test (IVT) processes
- The Profile creation wizard
- Other InstallShield for Multiplatforms (ISMP) installation programs
- InstallShield for Multiplatforms uninstall programs
- The IBM Rational Application Developer Agent Controller
Stop all Java processes, if necessary. If you install a maintenance package while a WebSphere Application Server-related Java process runs, IBM does not guarantee that the product can continue to run successfully, or without error.See the following technote for more information, Stop all WebSphere Application Server-related Java processes before using the Update Installer for WebSphere software.
- Locate a valid IBM SDK, Java Technology Edition for the Update Installer to use.
The Update Installer for WebSphere software requires a valid Java run time provided with WebSphere software. If the Update Installer program cannot locate a valid IBM or Sun SDK, such as the one shipped with WAS products, the Update Installer cannot install maintenance packages.
The Update Installer for WebSphere Software searches known locations for a suitable IBM SDK to use. In order, the Update Installer wizard looks for a valid Java Virtual Machine (JVM) in the following locations: - The install_root/updateinstaller/java directory (when updating the product SDK)
- The ../java/jre directory, which is the install_root/java/jre directory if you unpacked the Update Installer in the installation root directory.
This SDK is the preferred SDK. However, if you did not unpack the Update installer or the maintenance package that includes the Update Installer into the installation root directory, the default relative addressing scheme does not work. In such a case, source the setupCmdLine script or use the -is:javahome option on the update command to set the correct JAVA_HOME variable setting.
- The directory identified by one of the following environment variables:
- JAVA_HOME
- JAVAHOME
- JRE_HOME
- JREHOME
When no JVM is present in one of the first two locations, set one of the environment variables to point the Update Installer wizard to a valid JVM.The preferred method of setting the JAVA_HOME environment variable is using the setupCmdLine script provided with the WAS product. In some cases, a failure in sourcing the setupCmdLine script can result in the Update Installer program matching an SDK in a different order than the order described.
We can also force the installation to use the correct SDK with the following command:
./update -is:javahome install_root/java/jre
To use the setupCmdLine script to set the JAVA_HOME variable, perform the following procedure that is appropriate for your operating system:
- Open a command prompt window.
- Change directories to the install_root/bin directory.
- Issue the setupCmdLine.bat command.
- Use the same command prompt window to start the Update Installer, as described in a later step.
- Open a command shell window.
Important tip for SuSe Linux Enterprise System (SLES) users: Use either Terminal Emulator Superuser Mode or mlterm as the command shell.
- Change directories to the install_root/bin directory.
- Issue the . ./setupCmdLine.sh command. Notice the space between the periods. The special format for this command sources the command to make the setting active for all processes started from the command shell.
Important tip for SLES users: After the . ./setupCmdLine.sh command, issue the echo $JAVA_HOME command to verify that JAVA_HOME is set correctly.
- Use the same command shell window to start the Update Installer, as described in a later step.
See the following technote for more information, Using the setupCmdLine script to set JAVA_HOME before running the Update Installer for WebSphere software.
- Open a command prompt window.
- The install_root/updateinstaller/java directory (when updating the product SDK)
- Verify that the following prerequisite conditions are met:
- All of the product hardware and software prerequisites exist.
The official statement of supported hardware and software is on the IBM WAS supported hardware and software Web site.
- The WebSphere software that you are updating is correctly installed and is not corrupt.
- The WebSphere SDK, Java technology edition is not corrupt.
- The user is root on a Linux or UNIX system or a member of the administrator group on a Windows system.
- Change directories to the updateinstaller directory and use the update command to install the maintenance package.
- Click Relaunch to start the Update Installer again if the maintenance package causes the Update Installer to copy the Java 2 SDK.
If the maintenance package includes service to the SDK, the Update Installer copies the SDK and stops. Click Relaunch to start the Update Installer again. The Update Installer can then install the maintenance package.
- All of the product hardware and software prerequisites exist.
This procedure results in installing maintenance packages to update WebSphere software.
After installing a maintenance package, continue to use your WebSphere software.
install.txt
This topic describes the response file for installing service using the Update Installer for WebSphere Software.
Install an update silently using the options response file.
The install.txt file has one directive that identifies the backup file for installing a service update. Comments in the file describe how to set the string value.
The Update Installer for WebSphere Software wizard reads the options file to determine responses and does not display the graphical user interface. The following command uses a copy of the options file named myresponsefile.txt for a silent installation:
| ./update -options "responsefiles/myresponsefile.txt" -silent |
If you do not use the -silent option, the response file provides initial values for the graphical interface.
Location of the response file
The sample options response file is named install.txt. The file is in the install_root/updateinstaller/responsefiles directory after you unzip the Update Installer for WebSphere Software into the installation root directory of the WebSphere software product.
Installing silently
The options file supplies the values to the Update Installer wizard when installing silently. The wizard reads the options file to determine responses and does not display the graphical user interface. The following command uses a copy of the options file named myresponsefile.txt for a silent installation:
| update -options "myresponsefile.txt" -silent |
Response file user entry validation
In a silent installation, response file validation is coded into the installation. If the validation does not pass, the failure is recorded in the log files in the install_root/logs/update/tmp directory.
Location of the maintenance package to be installed
Identify where the maintenance package is located.
Default directive setting
| -W maintenance.package="" |
Valid setting
You must set this directive to the location of the PAK file. For example, you might specify the following location on a Linux system:
| /opt/IBM/WebSphere/AppServer/updateinstaller/maintenance/PQ20029.pak |
Error identifiers:
- Maintenance package maintenance_package_name is already installed on the system.
- Selected product is not supported.
- Configuration failed. The config action that failed was: configuration_action.
- Install the following prerequisite APARs before installing the current maintenance to the target product: list_ of_ prerequisite_ maintenance_ packages_ to_ install
- Install the following prerequisite maintenance packages before installing the package you are currently attempting to install: list_ of_ prerequisite_ maintenance_ packages_ to_ install
- Uninstall the following APARs before applying the current maintenance to the target product: list_ of_ prerequisite_ maintenance_ packages_ to_ uninstall
- Uninstall the following maintenance packages before applying the current maintenance to the target product: list_ of_ prerequisite_ maintenance_ packages_ to_ uninstall
- Unable to locate the correct version of the_update_installer. Looking for version version_identifier.
- Maintenance_package is not a valid maintenance package.
Alternate product location
Although applying maintenance to another product is possible, always use the Update Installer wizard within the directory structure of the product that you are updating. Do not use this directive unless absolutely necessary.Default directive setting
-W product.location="" Valid setting
You must set this directive to the installation root directory of the alternate product. For example, you might specify the following location on a Linux system:/opt/IBM/WebSphere/AppServer2 Error identifiers:
- Maintenance package maintenance_package_name is already installed on the system.
- Selected product is not supported.
- Configuration failed. The config action that failed was: configuration_action.
- Install the following prerequisite APARs before installing the current maintenance to the target product: list_ of_ prerequisite_ maintenance_ packages_ to_ install
- Install the following prerequisite maintenance packages before installing the package you are currently attempting to install: list_ of_ prerequisite_ maintenance_ packages_ to_ install
- Uninstall the following APARs before applying the current maintenance to the target product: list_ of_ prerequisite_ maintenance_ packages_ to_ uninstall
- Uninstall the following maintenance packages before applying the current maintenance to the target product: list_ of_ prerequisite_ maintenance_ packages_ to_ uninstall
- Unable to locate the correct version of the_update_installer. Looking for version version_identifier.
- Maintenance_package is not a valid maintenance package.
- Alternate_product_directory could not be validated as an existing directory.
Usage notes- The file is not a read-only file.
- Edit this file directly with your flat file editor of choice, such as Kate on SLES or WordPad on a Windows platform.
- The file must exist to perform a silent installation. The Update Installer wizard reads this file to determine installation parameters. Provide the fully qualified file path to the backup file.
- Save the copy of the options file in the responsefiles directory for best results.
Example install.txt fileEdit the version of the file that is included in the Update Installer for WebSphere Software ZIP file. The following example is not guaranteed to be an accurate representation of the actual file.
######################################################### # This is the silent install response file for # installing maintenance packages using the update # installer. # # A common use of an options file is to run the wizard # in silent mode. This lets # the options file author specify wizard settings # without having to run the # wizard in graphical or console mode. To use this # options file for silent mode # execution, *uncomment* and modify the parameters # defined within. # # Use the following command line when running the wizard # from the update installer directory: # # update -options responsefiles/install.txt -silent # ######################################################### # Used to input the maintenance package full filename # specification to be installed. # Edit as appropriate. # # ie. -W maintenance.package="C:\Program # Files\WebSphere\AppServer\ # updateinstaller\maintenance\PQ20029.pak" # # Note: If no package is specified, a default of the # last downloaded maintenance # package will be used (based on time stamp). # #-W maintenance.package= ######################################################### # Used to modify the product install location that will # be updated. # This value should be left commented out if the Update # Installer is # being run from the recommended location # # ie. -W product.location= # "C:\Program Files\WebSphere\AppServer" # # Note: If no location is specified, the parent # directory to update installer # will be used as default # #-W product.location="" ######################################################### # Do not edit these values. # # -W update.type="install"
Uninstalling maintenance packages
This topic describes how to use the Update Installer for WebSphere Software to uninstall interim fixes, fix packs, and refresh packs. The Update Installer for WebSphere Software is also known as the Update Installer program, the updateInstaller program, and the Update installation wizard.
Use the proper authorizations to successfully uninstall product updates. Use the Update Installer program as the root user on a Linux or UNIX platform, or as the administrator on a Windows platform.
The Update Installer wizard is an InstallShield for Multiplatforms wizard that runs with either a graphical user interface or in silent mode with a response file.
Important: See Known problems and workarounds for the update command.
The following descriptions contain reference information about uninstalling interim fixes, fix packs, and refresh packs on WAS products:
Overview of the uninstall procedure
To uninstall a maintenance package:
- Use the Update Installer to install the maintenance package, which creates a backup file in the install_root/properties/version/update/backup directory. IBM does not support user modifications to backup files.
- Use the Update Installer program to remove the maintenance package as described in this topic.
Viewing the fix level of the node
We can use the versionInfo command in the install_root/bin directory to display the exact fix and version level of the product. However, do not use the versionInfo command while installing or uninstalling a maintenance package.
Do not launch multiple copies of the Update Installer wizard at one time. Concurrent launches of the Update Installer program are not supported. Performing more than one update at the same time can produce unpredictable results, which might include a failed or faulty installation.
Required information
The graphical interface requires the following information...
Table 4. Information required when uninstalling a maintenance package
| Field | Valid values | Description | |||
| File path of the installation root directory of the WebSphere product and the Update Installer | Identify the installation root directory for one of the following products:
|
How to uninstall a maintenance package
The following procedure describes how to uninstall a maintenance package.
ol type="1" >
In addition, verify that the umask setting is 022. To verify the umask setting, issue the following command:
| umask |
|
|
| To set the umask setting to 022, issue the following command: |
|
|
| umask 022 |
|
|
|
| Before installing or uninstalling interim fixes, fix packs, and refresh packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WAS provides.
Stop all WebSphere Application Server-related Java processes that are running on the system where you are using the update installer program. For example, Java processes can include:
|
The Update Installer for WebSphere Software searches known locations for a suitable IBM SDK to use. In order, the Update Installer wizard looks for a valid Java Virtual Machine (JVM) in the following locations:
When no JVM is present in one of the first two locations, set one of the environment variables to point the Update Installer wizard to a valid JVM. The preferred method of setting the JAVA_HOME environment variable is using the setupCmdLine script provided with the WAS product. In some cases, a failure in sourcing the setupCmdLine script can result in the Update Installer program matching an SDK in a different order than the order described. We can also force the installation to use the correct SDK with the following command:
Using the SDK locks the SDK and prevents the update. Copy the SDK from the install_root/java/jre directory to the install_root/updateinstaller/java/jre directory. The Update Installer wizard uses the SDK in the install_root/updateinstaller/java directory if it is present. Alternatively, copy the IBM SDK from the parent product to a temporary location and use the -is:javahome ISMP parameter to identify the location as you run the Update Installer command:
| ||||||
Uninstall the interim fix on each application server node in a cell before uninstalling the maintenance package from the deployment manager node.
Issue one of the following commands to uninstall with the graphical interface:
Table 5. Update Installer commands for uninstalling with the graphical interface
Command example | Type of installation | Description |
update -W update.type="uninstall" | Graphical interface mode | Initializes the maintenance package field with the name of the maintenance package that was most recently installed. Accept all of the default values to uninstall the maintenance package with the most recent date stamp and time stamp. |
update -W product.location="e: \IBM\WebSphere\AppServer" -W update.type="uninstall" | Graphical interface mode | Overrides the graphical interface with the location of the WebSphere software to update. The default maintenance package to uninstall is the most recently installed maintenance package for that software. |
update -W backup.package="PQ20029.pak" -W update.type="uninstall" | Graphical interface mode | Overrides the maintenance package field with the name of the maintenance package to uninstall. |
update -W product.location="e: \IBM\WebSphere\AppServer" -W backup.package="PQ20029.pak" -W update.type="uninstall" | Graphical interface mode | Overrides the location of the WebSphere software to update and the name of the maintenance package to uninstall. |
update -options "responsefiles/file_name" | Graphical interface mode with an options file | Overrides all default values with values that you specified in the options response file. If you omit either value from the response file, the default maintenance package is the installed package with the most recent date stamp and time stamp. The default software is the software installed in the parent directory. |
Issue one of the following commands to use the silent interface:
Table 6. Update Installer commands for uninstalling in silent mode
| Command example | Type of installation | Description |
| update -W update.type="uninstall" -silent | Silent mode | Uninstalls the maintenance package with the most recent date stamp and time stamp to update the software that is installed in the parent directory. |
| update -W product.location="e: \IBM\WebSphere\AppServer" -W update.type="uninstall" -silent | Silent mode | Overrides the default location of the WebSphere software to update. The default maintenance package to uninstall is the most recently installed maintenance package for that software. |
| update -W backup.package="PQ20029.pak" -W update.type="uninstall" -silent | Silent mode | Overrides the interim fix field with the name of the maintenance package to uninstall. |
| update -W product.location="e: \IBM\WebSphere\AppServer" -W backup.package="PQ20029.pak" -W update.type="uninstall" | Silent mode | Overrides the location of the WebSphere software to update and the name of the maintenance package to uninstall. |
| update -silent -options "responsefiles/file_name" | Silent mode with an options file | Overrides all default values with values that you specified in the options response file.
If you omit either value from the response file, the default maintenance package is the installed package with the most recent date stamp and time stamp. The default software is the software installed in the parent directory. |
Rolling back changes to existing profiles: Some maintenance packages for WAS products, such as Refresh Pack 2, update existing profiles. If you roll back a maintenance package that contains a profile update, also use any undo scripts provided with the profile update script to roll back changes to the existing profiles.
The readme file for a maintenance package describes scripts that update and scripts that roll back profile fix levels. For example, Refresh Pack 2 for WAS includes required service for the JDBC resource provider templates in existing profiles. See the readme for the profile update and undo scripts for the JDBC-related update for more information.
Deleting profiles created by a service level that is now rolled back: See Profiles remain at the V6.0.2 level after roll back for a description of a limitation that requires profiles to be at the same service level or at a lower service level that the WAS product. For example, suppose that you install Refresh Pack 2 for Version 6.0 (V6.0.2), create a new profile, and then roll back Refresh Pack 2. You must delete the profile that you created at the V6.0.2 level to avoid possible problems.
Result of procedure
This procedure results in uninstalling maintenance packages to update WebSphere software.
After uninstalling maintenance packages, we can continue to use the WebSphere software.
uninstall.txt
This topic describes the response file for uninstalling service using the Update Installer for WebSphere Software.
Uninstall an update silently using the options response file.
The uninstall.txt file has one directive that identifies the backup file for uninstalling a service update. Comments in the file describe how to set the string value.
The Update Installer for WebSphere Software wizard reads the options file to determine responses and does not display the graphical user interface. The following command uses a copy of the options file named myresponsefile.txt for a silent uninstall:
| ./update -options "responsefiles/myresponsefile.txt" -silent |
If you do not use the -silent option, the response file provides initial values for the graphical interface.
Location of the response file
The sample options response file is named uninstall.txt. The file is in the install_root/updateinstaller/responsefiles directory after you unzip the Update Installer for WebSphere Software into the installation root directory of the WebSphere software product.
Uninstalling silently
The options file supplies the values to the Update Installer wizard when uninstalling silently. The wizard reads the options file to determine responses and does not display the graphical user interface. The following command uses a copy of the options file named myresponsefile.txt for a silent uninstall:
| update -options "myresponsefile.txt" -silent |
Response file user entry validation
In a silent uninstall, response file validation has been coded into the installation. If the validation does not pass, the failure is recorded in the log files in the install_root/logs/update/tmp directory.
Location of the maintenance package to be uninstalled
Default directive setting
| -W backup.package="" |
Valid setting
You must set this directive to the location of the backup file. The backup file reverses the application of the maintenance. For example, you might specify the following location on a Linux system:
| /opt/properties/version/update/backup/maintenance_package_to_uninstall |
Error identifiers:
- The maintenance package cannot be uninstalled. Uninstalling the maintenance would break the following superseding maintenance packages. Uninstall the superseding maintenance packages first: list_of_superseding_maintenance_packages
- This maintenance package cannot be uninstalled. The following maintenance packages are dependent on the package that you are attempting to uninstall: list_of_dependent_maintenance_packages
- This maintenance package cannot be uninstalled. The following maintenance packages are dependent on the APARs you are attempting to uninstall: list_of_dependent_maintenance_packages
- No installation backup packages are available for uninstalling maintenance.
Alternate product location
Although uninstalling maintenance from another product is possible, always use the Update Installer wizard from the directory structure of the product that you are updating. Do not use this directive unless absolutely necessary.Default directive setting
-W product.location="""" Valid setting
You must set this directive to the installation root directory of the alternate product. For example, you might specify the following location on a Linux system:/opt/IBM/WebSphere/AppServer2 Error identifiers:
- The maintenance package cannot be uninstalled. Uninstalling the maintenance would break the following superseding maintenance packages. Uninstall the superseding maintenance packages first: list_of_superseding_maintenance_packages
- This maintenance package cannot be uninstalled. The following maintenance packages are dependent on the package that you are attempting to uninstall: list_of_dependent_maintenance_packages
- This maintenance package cannot be uninstalled. The following maintenance packages are dependent on the APARs you are attempting to uninstall: list_of_dependent_maintenance_packages
- No installation backup packages are available for uninstalling maintenance.
Usage notes- The file is not a read-only file.
- Edit this file directly with your flat file editor of choice, such as Kate on SLES or WordPad on a Windows platform.
- The file must exist to perform a silent uninstall. The Update Installer wizard reads this file to determine uninstall parameters. Provide the fully qualified file path to the backup file.
- Save the copy of the options file in the responsefiles directory for best results.
Example uninstall.txt file
Edit the version of the file that is included in the Update Installer for WebSphere Software ZIP file. The following example is not guaranteed to be an accurate representation of the actual file.#########################################################
# This is the silent install response file for
# uninstalling maintenance packages
# using the update installer.
#
# A common use of an options file is to run the wizard
# in silent mode. This lets
# the options file author specify wizard settings
# without having to run the
# wizard in graphical or console mode. To use this
# options file for silent mode
# execution, *uncomment* and modify the parameters
# defined within.
#
# Use the following command line when running the wizard
# from the update
# installer directory:
#
# update -options responsefiles/uninstall.txt -silent
#
########################################################
#########################################################
# Used to input the maintenance backup package file name
# to be uninstalled.
# This is the same file name as the package that was
# originally installed.
# A maintenance package can only be uninstalled if a
# backup package exists.
#
# ie. -W backup.package="PQ20029.pak"
#
# Note: If no package is specified, a default of the
# last installed maintenance
# package will be used.
#
#-W backup.package=""
#########################################################
# Used to modify the product install location that will
# be updated.
# This value should be left commented out if the Update
# Installer is
# being run from the recommended location
#
# ie. -W product.location=
# "C:\Program Files\WebSphere\AppServer"
#
# Note: If no location is specified, the parent
# directory to update installer
# will be used as default
#
#-W product.location=""
#########################################################
# Do not edit these values.
#
-W update.type="uninstall"
update command
The update command is the Update Installer for WebSphere Software program. The Update Installer wizard is also known as the Update installation wizard, the Update Installer program, and the updateInstaller program.
The Update Installer program installs and uninstalls interim fixes, fix packs, and refresh packs to update WebSphere software.
The update command calls the Update Installer program to install and uninstall service to update WebSphere software. This topic describes the Update Installer command and its command-line parameters.
The following descriptions contain reference information about the command.
See Installing maintenance packages and Uninstalling maintenance packages for information about using the command and all of the command options.
Installing multiple interim fixes
Use a script to issue more than one command. Each command identifies one maintenance package to install.
Example 1
| ...
./update -W maintenance.package=/opt/IBM/WebSphere/AppServer/updateinstaller/maintenance/PK20028.pak -silent ./update -W maintenance.package=/opt/IBM/WebSphere/AppServer/updateinstaller/maintenance/PK20029.pak -silent |
|
Automating maintenance operations
Most fix packs and refresh packs include some maintenance for the IBM SDK, Java technology edition in the install_root/java/jre directory. When a refresh pack, fix pack, or interim fix updates the SDK, the Update Installer for WebSphere Software program clones the SDK in the product by starting an ISMP process to copy the SDK to the install_root/updateinstaller/java directory:
| install_root
/updateinstaller /java |
To use a script to perform a silent maintenance installation, launch the Update Installer program twice. The first command clones the SDK only and does not automatically relaunch the Update Installer program. The second command uses the cloned SDK to update the product and the SDK in the product.
The Update Installer for WebSphere always uses the SDK in the install_root/updateinstaller directory if the SDK is present.
ol type="1" >
| update -silent [other_options] -W relaunch.active=false |
|
|
| For example, use the following command to clone the SDK: |
|
|
| /opt/WebSphere/AppServer/updateinstaller/update \
-silent \ -W relaunch.active=false \ |
|
|
| Specify the interim fix in the first command if the interim fix is not the last maintenance package that you downloaded.
In the V6.0.1 Update Installer, the parameter was -W relaunchwizardexecInstallWizardBean.active=false. Note: Omit the Linux and UNIX line-continuation characters (\) when issuing the command on one line. |
|
|
| update -silent |
|
|
| The Update Installer program uses the cloned copy of the SDK in the install_root/updateinstaller directory at the next invocation of the command. For example, use the following command to install the update using the cloned SDK: |
|
|
| /opt/WebSphere/AppServer/updateinstaller/update \
-silent -W maintenance.package=\ "/opt/WebSphere/AppServer/updateinstaller/maintenance/\ 6.0.1.0-WS-WAS-LinuxIA32-RP0000001.pak" \ -W update.type="install" \ -W product.location="/opt/WebSphere/AppServer" |
|
|
| Note: Omit the Linux and UNIX line-continuation characters (\) when issuing the command on one line. |
|
|
Logging
The following sections describe logging that occurs when installing and uninstalling service.
Logs created when installing service
If no installation log file exists, refer to the temporary log file in the install_root/logs/update/tmp directory. If all validations pass, the installation occurs.
Then the Update Installer program creates the install_root/logs/update/maintenance_package.install directory.
Within the directory are the updatelog.txt file, the compressed updatetrace.log.gz file, and the compressed updateconfig.log.gz file. The updateconfig.log.gz file exists only when the installation of service uses the internal configuration manager utility to run ANT scripts.
Logs created when uninstalling service
If no log file exists after uninstalling an interim fix, refer to the temporary log file in the install_root/logs/update/tmp directory. If all validations pass, the uninstall procedure occurs.
Then the Update Installer program creates the install_root/logs/update/maintenance_package.uninstall directory.
Within the directory are the updatelog.txt file, the compressed updatetrace.log.gz file, and the compressed updateconfig.log.gz file. The updateconfig.log.gz file exists only when the removal of service uses the internal configuration manager utility to run ANT scripts.
Indicators of success
The log file includes an indicator of success:
INSTCONFSUCCESS
The current operation was successful. You do not need to review the log file any further.
INSTCONFPARTIALSUCCESS
The current operation was partially successful. System should still be in a usable state, however some noncritical actions have failed. Consult the log file to determine what has failed and how to recover from the failure, if possible.
INSTCONFFAILED
The current operation failed. The system is no longer in a usable state. Consult the log file for more information.
Known problems and workarounds for the update command
The Update Installer program displays its version information in the title bar of the graphical interface. Version information is stored in the version.txt file in the updateinstaller directory.
A new version might ship to correspond to any new maintenance package. Information in the version.txt file is displayed prominently in the title bar of the wizard and is also recorded in the updatelog.txt file.
Always download and use the latest version of the Update Installer wizard when installing an interim fix.
The following table describes known problems and when the problems were resolved. See the Workarounds section that follows the table for more information.
Description of problem
| Workaround
| Version with resolution
|
| Product uninstall does not remove the updated product correctly. | Product uninstall | Current problem |
| Relaunch action for SDK updates does not relaunch the update installer.
| Relaunch fails | Current problem |
| Always use the most current version of the Update Installer for WebSphere Software to install maintenance packages | Use the most current version | Current problem |
| Control returns prematurely to the command line when the Update Installer rolls back an updated IBM Software Development Kit (SDK). | Control returns prematurely | Limitation |
| The Update Installer fails to relaunch after copying the IBM Software Development Kit (SDK) if not enough disk space is available for installation | Relaunch failure due to insufficient disk space | Limitation |
| Non-root profiles start with error after installing Refresh Pack 2 | Service for profiles can change file owner | Limitation |
| Problem in cloning the SDK for updates to the product SDK | SDK does not copy correctly | V6.0.2 |
| Profile update and undo scripts are limited to SBCS and to characters without pronunciation keys due to operating system limitations | Accented characters in profile file path cause problems | Limitation |
| Profiles can exist at the V6.0.2 level after rolling back Refresh Pack 2. | Profiles remain at the V6.0.2 level after roll back | Limitation |
| InstallShield for Multiplatforms (ISMP) detects Windows 2003 64-bit AMD platform as Windows XP 64-bit AMD platform | ISMP incorrectly detects Windows 2003 64-bit AMD | V6.0.2 |
Workarounds
The following section describes workarounds for current problems.
- Product uninstall
Problem: The product uninstaller for Version 6.0.x.x cannot delete all files and directories that exist after installing a refresh pack or a fix pack.
Description: If you apply a refresh pack or a fix pack using the update installer program and then uninstall the whole product using the Version 6.0.0.0 product uninstaller program, many files are left on the system.
Cause: The product uninstaller program will be fixed in a later release.
Customer action: Two workarounds exist. Use either of the following workarounds to circumvent the problem:
- Uninstall all maintenance packages using the update installer program before uninstalling the product.
- Delete all remaining directories after uninstalling the product.
- Relaunch fails
Problem: The update installer program cannot launch a second ISMP process that uses the cloned copy of the SDK in the install_root/updateinstaller/java/jre directory. Description: When a refresh pack, fix pack, or interim fix updates the IBM SDK, Java Technology edition (SDK), the update installer program clones the SDK in the product by starting an ISMP process to copy the SDK to the install_root/updateinstaller/java/jre directory:
After copying the SDK, the update installer program stops the first ISMP process and launches a second process that uses the SDK in the install_root/updateinstaller/java/jre directory.install_root
/updateinstaller
/java
/jre
Cause: The update installer program will be fixed in a later release.
Customer action: If this problem occurs, launch the update installer program again. The update installer program uses the cloned copy of the SDK in the install_root/updateinstaller/java/jre directory if the copy is present.
If the cloning fails, copy the SDK before starting the Update Installer wizard:
- Copy the install_root/java/jre directory to the install_root/updateinstaller/java directory.
- Change directories to the install_root/updateinstaller directory.
- Start the installation with the following command:
./update -is:javahome install_root/updateinstaller/java
- Use the most current version
Problem: Older versions of the update installer program can fail to install newer maintenance packages properly. Description: If the installation fails, messages about missing prerequisites do not display. Instead of messages about specific prerequisite failures, a blank failure panel displays the following message:
Contrary to the message, no additional messages display.Prerequisite checking has failed. Failure messages follow:
Cause: New maintenance packages often require a newer version of the update installer program.
Customer action: If the installation fails with the preceding error message, download the latest update installer program and reinstall the maintenance package. See the download page for the Update Installer to download the latest version.
- Control returns prematurely
Problem: Control returns prematurely to the command line when the Update Installer rolls back an updated IBM Software Development Kit (SDK). Some maintenance packages, such as Refresh Pack 2 for WAS V6.0.0, include service for the IBM Software Development Kit, Java Technology Edition (SDK). When installing maintenance packages that include service to the SDK, the Update Installer for WebSphere Software copies or clones the SDK of the existing product. When you relaunch the Update Installer using the copied SDK, the product SDK is updated.
If you delete the copied SDK to free disk space after the maintenance package is installed, the Update Installer copies the SDK again if you uninstall or roll back the maintenance package.
Description: We can start the Update Installer wizard from the command line in silent mode, to roll back a maintenance package that includes service to the SDK. The following example shows such a command. The command in the example uses a response file to identify a maintenance package and the uninstall action:
If you roll back a maintenance package that includes service to the SDK, the Update Installer copies the SDK and then automatically relaunches to roll back the maintenance package../update -options responsefiles/uninstall.txt -silent
As the Update Installer relaunches, control returns to the command line even though the Update Installer is still running in the background.
Customer action: On Linux and UNIX systems, we can work around the problem by copying the SDK yourself before launching the Update Installer. Use the following procedure:
- Copy the install_root/java/jre directory to the install_root/updateinstaller/java directory.
- Change directories to the install_root/updateinstaller directory.
- Start the installation with the following command:
./update -options responsefiles/uninstall.txt \
-silent \
-is:javahome install_root/updateinstaller/java
Or, we can let the Update Installer automatically clone the SDK and ignore the implication that the command line is ready to issue another command when control returns at the relaunch. The Update Installer is still running until it completes the roll back of the maintenance package. See the install_root/logs/update/maintenance_package_name/updatelog.txt log file to determine when the operation is complete.
- Relaunch failure due to insufficient disk space
Problem: Relaunch failure for insufficient disk space after copying the IBM Software Development Kit (SDK) if not enough disk space is available for installation. Some maintenance packages, such as Refresh Pack 2 for WAS V6.0.0, include service for the IBM Software Development Kit, Java Technology Edition (SDK). When installing maintenance packages that include service for the SDK, the Update Installer for WebSphere Software copies the SDK of the existing product. Relaunching the Update Installer using the copied SDK allows the product SDK to be updated.
A possibility exists that the Update Installer can perform the first part of the update that copies the SDK, but that copying the SDK reduces the amount of available space to the point that the Update Installer cannot relaunch to continue the update.
When the problem occurs, if you click Relaunch. nothing happens. The relaunch of the Update Installer does not occur. If you attempt to start the Update Installer manually with the update command, the following error occurs:
Description: A design limitation prevents the Update Installer from checking for available disk space before copying the SDK. During relaunch, the Java Virtual Machine (JVM) attempts to start but must stop because of the lack of disk space. Without the JVM, the Update Installer cannot start.Initializing InstallShield Wizard... Searching for Java(tm) Virtual Machine...
A suitable JVM could not be found. Please run the program again using the option
-is:javahome JAVA_HOME_DIR
Error writing file = There may not be enough temporary disk space.
Try using -is:tempdir to use a temporary directory on a partition
with more disk space.
Customer action: Each maintenance package includes space requirements for the file system that contains the installation root directory of the WAS product, and for the system temporary directory.
If an interim fix does not state a disk requirement, verify that 100 MB of space is available in the file system and another 100 MB of space is available in the system temporary directory.
For example, the readme file for Refresh Pack 2 for V6.0.0 includes service for the SDK states that the amount of free temp space required is 250 MB and that the free space required on the file system is 600 MB.
Service for profiles can change file owner
Problem: Maintenance packages with required service for existing profiles can change file ownership. The root user runs the Update Installer wizard to install maintenance packages for WAS Version 6.x products. Some maintenance packages include required service for existing profiles.
Non-root users can own profiles on Linux and UNIX systems. If the root user updates an existing non-root profile, any new files that the maintenance package creates are owned by the root user instead of the non-root user.
When an application server in a non-root profile starts, it attempts to load the new files. Because the new files belong to the root user, the application server encounters an error and issues a message that is similar to the following example:
Description: Installing a maintenance package that contains service for a non-root profile changes the ownership of any new files that the maintenance package creates. The user who installs the maintenance becomes the owner of the new files. The root user is required to install maintenance for Version 6.x. Therefore, after installing the maintenance, root owns any new files in the profile.ADMR0104E: The system is unable to read document
cells/MyCell/nodes/mynode/ node-metadata.properties:
java.io.IOException: No such file or directory
For example, Refresh Pack 2 has required service for the Java Database Connectivity (JDBC) resource provider templates. The required service backs up some existing files and creates new versions of the files. The new files are owned by the user who installs the maintenance package. When the root user installs Refresh Pack 2, the root user owns the following JDBC-related files:
- profile_root/logs/updateProfileJdbcTemplate.log
- profile_root/config/templates/system/jdbc-resource-provider-only-templates.xml
- profile_root/config/templates/system/jdbc-resource-provider-templates.xml
Customer action: To fix the problem, reassign ownership of the entire profile directory to the non-root user (wsdemo in the following example). The profile_root variable in the following example is the profile directory that the non-root user owns.The root user can make the wsdemo user the owner of the profile directory with the following command:
For more information about the JDBC resource provider templates that are updated in Refresh Pack 2 for WebSphere Application Server, see UPDI: Refresh Pack 2 for WAS includes required service for the JDBC resource provider templates in existing profiles.chown -R wsdemo profile_root
The description of the wasprofile command describes a scenario for creating non-root profiles. See wasprofile command for more information.
- SDK does not copy correctly
Problem: A defect in previous versions of the Update Installer wizard is now fixed in V6.0.2. The error prevents the SDK from being cloned when there is service to the product SDK.
The error causes the following entries in the log file and the trace file entries.Failure: The JDK copy has failed
Entries in the updatelog.txt file
Entries in the upatetrace.txt file/usr/IBM/WebSphere/AppServer/updateinstaller/././java/jre Target:
/usr/IBM/WebSphere/AppServer/updateinstaller/java:, percent complete:
0% (Jun 7, 2005 1:17:31 PM), Install,
com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction, err, null
(Jun 7, 2005 1:17:31 PM), Install,
com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction, err, null
(Jun 7, 2005 1:17:31 PM), Install,
com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction, err,
java.io.IOException
Customer action: Manually copy the SDK before starting the Update Installer when the maintenance package contains service for the product SDK. Or, use the V6.0.2 level of the Update Installer to install the maintenance package.<message>java.io.IOException
at
com.ibm.ws.install.ni.framework.io.DiskFileSystem.setPermissions(DiskFil
eSystem.java:188)
at
com.ibm.ws.install.ni.framework.io.FileSystemEntry.setPermissions(FileSy
stemEntry.java:167)
at
com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction.copySourceToT
arget(ISMPCopyDirectoryAction.java:143)
at
com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction.execute(ISMPC
opyDirectoryAction.java:66)
at
com.installshield.wizard.RunnableWizardBeanContext.run(RunnableWizardBea
nContext.java:21)
</message>
Copy the product SDK to the install_root/updateinstaller/java/jre directory.
- Copy the install_root/java/jre directory to the install_root/updateinstaller/java directory.
- Change directories to the install_root/updateinstaller directory.
- Start the installation with the following command:
./update -is:javahome install_root/updateinstaller/java
- Accented characters in profile file path cause problems
Problem: Shell scripts that perform service updates to existing profiles can fail if the profile path or the profile name contains accented characters. Failure symptoms include a partial success message in the updatelog.txt file.
For example, the updateProfileJdbcTemplates.ant script runs during the installation of Refresh Pack 2 on WAS products.
In general, if the following message is present in the updateconfig.log file, run the JACL script using the wsadmin command to perform a manual update of all potentially affected profiles.
Running the script does not harm profiles that are already updated.<message>
Result of executing
C:\WAS60GM\properties\version\update\config\install\
updateProfileJdbcTemplates.ant was: false
</message>
Description: Shell scripts on some operating systems cannot contain single-byte characters with pronunciation keys.
If the file path to the profile or the profile name includes single-byte characters with pronunciation keys, such as o-umlaut (a diacritic mark over the o), c-cedilla (a mark is under the c), or characters with other keys, the script might not run correctly.
Customer action: Run a failing ANT script by copying the content to the command line and running the wsadmin command directly.
See the documentation for each failing ANT script to determine how to run its underlying JACL script using the wsadmin command. For example, see the UPDI: Refresh Pack 2 for WAS includes required service for the JDBC resource provider templates in existing profiles technote for more information about running the updateProfileJdbcTemplates.jacl script.
- Profiles remain at the V6.0.2 level after roll back
Problem: Profiles can exist at the V6.0.2 level after rolling back Refresh Pack 2.
If you install Refresh Pack 2 for a WAS product and create a new profile, the resulting profile is at the V6.0.2 level. If you roll back Refresh Pack 2 with the following command,
update -W update.type="uninstall"
the fix level of the product is either V6.0.0 or V6.0.1, but any V6.0.2 profiles still exist at the V6.0.2 level. A V6.0.2 profile might not start or might run with errors if the fix level of the product is at a lesser level.
The problem can also occur within a cell, when the deployment manager, the node agent, or a federated application server is at the V6.0.2 level, but the product level is either V6.0.0 or V6.0.1.
Description: V6.0.2 uses multihome support for profiles, which results in an * (asterisk) as the value of the host name field in the DCS_UNICAST_ADDRESS endpoint. V6.0.0 and V6.0.1 use a string value for the host name field.
V6.0.2 profiles have a value for host name that the V6.0.0 or V6.0.1 product cannot interpret. The result is an error when the V6.0.2 profile starts. Therefore, a new V6.0.2 profile is not supported in a V6.0.0-level or V6.0.1-level product.
Customer action: Delete the V6.0.2-level profiles and recreate them at the current product level.
- ISMP incorrectly detects Windows 2003 64-bit AMD
Problem: The InstallShield for Multiplatforms (ISMP) Update Installer wizard detects the Windows 2003 64-bit AMD platform as a Windows XP 64-bit AMD platform when installing Refresh Pack 2 for a WAS product.
The Installation wizard that installs WAS V6.0.1.1 on Windows 2003 64-bit AMD platforms, logs the results of the installation in the log.txt file.
When installing Refresh Pack 2 (V6.0.2) on 64-bit AMD Windows 2003 platforms, the Update Installer logs the results of the installation of the maintenance package in the updatelog.txt file.
Both log files have entries that incorrectly identify the Windows 2003 system as a Windows XP system.
The following example shows entries that might be in the updatelog.txt file:
(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, Java Install Path:
C:\ND\IBM\WebSphere\AppServer\updateinstaller\java(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, OS Name: Windows XP(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, OS Architecture: amd64(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, OS Version: 5.2 build 3790 Service Pack 1(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, Current User ID: amd41(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, Current User Home: C:\Documents and Settings\Administrator(date) UpdateInstaller,
com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction,
msg1, Current Working Directory: C:\ND\IBM\WebSphere\AppServer
Description: The Update Installer for WebSphere Software is using the IBM Software Development Kit (SDK), Java Technology Edition, that is included with the V6.0.1.1 product. The SDK causes the erroneous platform identification. Customer action: While installing Refresh Pack 2 (V6.0.2), the Update Installer updates the SDK. The updated SDK can correctly identify the Windows 2003 operating system platform. Further use of the Update Installer program, such as to install an interim fix or a fix pack for V6.0.2, creates entries in the updatelog.txt file that correctly identify the Windows 2003 system.
Ignore the incorrect platform specification in the log files for the V6.0.1.1 installation and the installation of Refresh Pack 2. WAS V6.0.2 does support the Windows 2003 64-bit AMD platform in spite of the messages in the log files.
See also
install.txt
Uninstalling service
update command
Known problems and workarounds for the update command
Related Information
Product version information