Update Installer for WAS V6.0

 

+

Search Tips   |   Advanced Search

 

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:

  1. Back up and delete the updateinstaller directory of the existing update installer.

  2. 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.

  3. Unpack the ZIP or TAR file that you downloaded to create the updateinstaller directory and several subdirectories, including the maintenance directory.

  4. Interim fix only: Download the interim fix from the Support Web site into the maintenance directory.

  5. 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.

 


Update existing profiles

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 you 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:

  • IBM WAS
  • IBM WAS - Express
  • Embedded version of the IBM WAS - Express
  • IBM WAS Network Deployment
  • IBM WebSphere Extended Deployment
  • IBM Application Client for WAS
  • IBM WebSphere Business Integration Server Foundation
  • Web server plug-ins for WAS
  • IBM HTTP Server
Download a maintenance package or the Update Installer to a temporary disk.

Unpack the maintenance package into the installation root directory of the product.

Unpack the Update Installer also within the installation root directory of every product that you intend to update.

The Update Installer application installs a maintenance package to the product in its parent directory by default.

File name of the maintenance package to install. Select a maintenance package to install from the maintenance directory. The default maintenance package is the package with the latest date stamp and time stamp.

 


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.

 


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.

  1. 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.

  2. Set umask to 022.

  3. Back up any files and subdirectories in...

    install_root/updateinstaller

    ...if necessary.

  4. Delete...

    install_root/updateinstaller/maintenance

    ...and all of its subdirectories.

  5. 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.

  6. 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.

  7. 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.

  8. Unpack the ZIP file or the TAR file.

    1. Unzipping a maintenance package ZIP file

      1. Open the ZIP file with your unzip utility, such as WinZip.

      2. 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.

    2. 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:

      •  /usr/IBM/WebSphere/AppServer
      •  /opt/IBM/WebSphere/AppServer

      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:

      • /usr/IBM/WebSphere/AppClient
      •  /opt/IBM/WebSphere/AppClient

      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.

  9. 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:

  10. Use the Windows Services panel to stop all services for WAS processes.

  11. 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.


  12. 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 that is 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:

    1. The install_root/updateinstaller/java directory (when updating the product SDK)

    2. 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.

    3. 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.

      You 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:


      [Windows]

      1. Open a command prompt window.

      2. Change directories to the install_root/bin directory.

      3. Issue the setupCmdLine.bat command.

      4. Use the same command prompt window to start the Update Installer, as described in a later step.

      [Linux][UNIX]

      1. 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.

      2. Change directories to the install_root/bin directory.

      3. 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.

      4. 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.


  13. 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.

      Network Deployment only: Install the maintenance package on the deployment manager node before installing the maintenance package on each application server node that you intend to update.

      Use the following command syntax to install the last maintenance package that you downloaded. The Update Installer wizard runs as a background process and does not display the graphical user interface when running in silent mode:

      update -silent

      Or, issue the update command to start the graphical user interface:

      update

      The following tables show all of the options that are available when using the update command. The commands in the first table each start the Update Installer wizard with a graphical user interface. Commands in the second table cause the Update Installer wizard to run in silent mode.

       


      Command example Type of installation Description
      update Graphical interface mode Initializes the maintenance package field with the name of the maintenance package that has the most recent date stamp and time stamp.
      Accept all of the default values to install the maintenance package with the most recent time stamp.
      update -W prereqsfailedpanelInstallWizardBean.active
      = "false"
      Graphical interface mode that bypasses prerequisites checking Initializes the maintenance package field with the name of the maintenance package that has the most recent date stamp and time stamp. Bypasses prerequisites checking.
      update -options "responsefiles/file_name" Graphical interface mode with an options file Overrides all graphical interface values with values that you specified in the options response file.
      If you omit either value, the default maintenance package is the one with the most recent date stamp and time stamp. The default software is the software installed in the parent directory.
      update -W maintenance.package=
      "e: /IBM/WebSphere/AppServer /updateinstaller/maintenance/PQ20029.pak"
      Graphical interface mode Overrides the name of the maintenance package to apply.
      update -W product.location=
      "e: /IBM/WebSphere/AppServer"
      Graphical interface mode Overrides the location of the WebSphere software to update.
      update -W product.location="e: /IBM/WebSphere/AppServer" -W maintenance.package="e: /IBM/WebSphere/AppServer /updateinstaller/maintenance/PQ20029.pak" Graphical interface mode Overrides the location of the WebSphere software to update and the name of the maintenance package to apply.

       



      The commands in the following table each start the Update Installer wizard in silent mode without the graphical user interface:

      Table 3. Update Installer commands for installing in silent mode

      Command example Type of installation Description
      update -silent Silent mode Installs the maintenance package with the most recent time stamp to update the software that is installed in the parent directory.
      update -silent -W prereqsfailedpanelInstallWizardBean.active= "false" Silent mode that bypasses prerequisites checking Installs the maintenance package with the most recent time stamp to update the software that is installed in the parent directory. Bypasses prerequisites checking.
      update -W maintenance.package="e: /IBM/WebSphere/AppServer /updateinstaller/maintenance /PQ20029.pak" -silent Silent mode By default, the wizard installs the maintenance package with the most recent date stamp and time stamp.
      Use the package override to install another maintenance package. You do not need a response file. The default software is the software installed in the parent directory.
      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 one with the most recent date stamp and time stamp. The default software is the software installed in the parent directory.
      update -W product.location="e: /IBM/WebSphere/AppServer" -silent Silent mode Updates the WebSphere software specified in the command with the maintenance package that has the most recent date stamp and time stamp. The silent installation does not refer to a response file.
      update -W product.location="e: /IBM/WebSphere/AppServer" -W maintenance.package="e: /IBM/WebSphere/AppServer /updateinstaller/maintenance/ PQ20029.pak" -silent Silent mode Updates the WebSphere software specified in the command with the maintenance package specified in the command. The silent installation does not refer to a response file.

    • 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.

Result

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 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 
    # 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:

  1. 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.

  2. Use the Update Installer program to remove the maintenance package as described in this topic.

 



Viewing the fix level of the node

You 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:

  • IBM WAS
  • IBM WAS - Express
  • Embedded version of the IBM WAS - Express
  • IBM WAS Network Deployment
  • IBM WebSphere Extended Deployment
  • IBM Application Client for WAS
  • IBM WebSphere Business Integration Server Foundation
  • Web server plug-ins for WAS
The Update Installer application defaults to select the product in its parent directory.
File name of the maintenance package to uninstall. Select a maintenance package to uninstall from the install_root/properties/version/ update/backup directory. The default maintenance package is the package with the latest date stamp and time stamp in the install_root /properties/version/ update/backup directory.

 



How to uninstall a maintenance package
The following procedure describes how to uninstall a maintenance package.

ol type="1" >

  • Log on as a user profile with *ALLOBJ special authority.

  • Log on as root on a Linux or UNIX operating system, or as a member of the administrator group on a Windows system.

    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

  • Change directories to the updateinstaller directory in the installation root directory.

    • [Windows]

      WebSphere Application Server products:
      For example, the C:\Program Files\IBM\WebSphere\AppServer directory.

      Application Client:
      For example, the C:\Program Files\IBM\WebSphere\AppClient directory.

      Web server plug-ins:
      For example, the C:\Program Files\IBM\WebSphere\Plugins directory.

      IBM HTTP Server:
      For example, the C:\Program Files\IBM HTTP Server directory.

      WebSphere Application Server Extended Deployment:
      For example, the C:\Program Files\WebSphere\DeploymentManager directory.

      WebSphere Application Server Edge Components:
      Not applicable. Use the Windows Add/Remove Software utility to remove the Edge product on Windows platforms.Edge updates do not use the Update Installer to install or remove the update.

    • [Linux][UNIX]

      Change directories to the installation root directory of the product that you are updating:

      WebSphere Application Server products:
      Installation root directory:

      •  /usr/IBM/WebSphere/AppServer
      •  /opt/IBM/WebSphere/AppServer

        Application Client:
        Installation root directory:

        •  /usr/IBM/WebSphere/AppClient
        •  /opt/IBM/WebSphere/AppClient

          Web server plug-ins:
          Installation root directory:

          •  /usr/IBM/WebSphere/Plugins
          •  /opt/IBM/WebSphere/Plugins

            IBM HTTP Server:
            Installation root directory:

            •  /usr/IBMIHS/
            •  /opt/IBMIHS

              WebSphere Application Server Extended Deployment:
              Installation root directory:

              •  /usr/WebSphere/DeploymentManager
              •  /opt/WebSphere/DeploymentManager

                WebSphere Application Server Edge Components:
                Not applicable. Use the native operating system uninstaller to remove the Edge product packages from Linux and UNIX systems. Edge updates do not use the Update Installer to install or remove the update.


  • [Windows] 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.


  • Determine if you are removing a maintenance package that updated the IBM SDK, Java Technology Edition. If so, you can clone the IBM SDK from the parent product to the Update Installer wizard directory. Cloning the SDK copies the install_root/java/jre directory to the install_root/updateinstaller/java directory.

    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:

    1. The install_root/updateinstaller/java directory (when updating the product SDK)

    2. The ../java/jre directory, which is usually the install_root/java/jre directory (preferred SDK to use)

    3. The directory identified by one of the following environment variables on a Linux or UNIX system:

      1. JAVA_HOME
      2. JAVAHOME
      3. JRE_HOME
      4. 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.

    You can also force the installation to use the correct SDK with the following command:


    Important: To uninstall a fix pack or interim fix for the IBM SDK in the parent product, do not start the Update Installer wizard using the product SDK that you intend to update.

    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:

    update -is:javahome= "my_fully_qualified_temp_SDK_location"


    ./update -is:javahome install_root/java/jre

  • Use the Update Installer to uninstall the maintenance package.

    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, you 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.

    [Linux][UNIX] 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


    If any maintenance package contains service for the IBM Software Developer Kit (SDK), the resulting asynchronous return to the script causes multiple instances of the Update Installer to run, which is not allowed. Use the following procedure to avoid the problem:

    1. Create the default cloned SDK location within the updateinstaller directory.

      For example, the following command creates the same directory for the SDK that the Update Installer creates when it clones the SDK automatically:

      mkdir /opt/IBM/WebSphere/AppServer/updateinstaller/java

    2. Copy the SDK from the product installation root to the default clone location.

      Copy the contents of the install_root/java/jre directory to the install_root/updateinstaller/java directory.

      For instance, the command for a Linux system might resemble the following example:

      cp -rf /opt/IBM/WebSphere/AppServer/java/jre/* --target-directory='/opt/IBM/WebSphere/AppServer/updateinstaller/java'

    3. Edit the script to change the command for the maintenance package that installs the update to the SDK. Or change all of the commands in the script.

      ...
      ./update -is:javahome /opt/IBM/WebSphere/AppServer/updateinstaller/java -W maintenance.package=/opt/IBM/WebSphere/AppServer/updateinstaller/maintenance/PK20028.pak -silent

      ./update -is:javahome /opt/IBM/WebSphere/AppServer/updateinstaller/java -W maintenance.package=/opt/IBM/WebSphere/AppServer/updateinstaller/maintenance/PK20029.pak -silent


    See the UPDI: Control returns prematurely to the command line when the Update Installer rolls back an updated IBM Software Development Kit (SDK) technote for more information about asynchronous operations when the Update Installer is cloning the SDK.

    [Windows] Example 2
    The InstallShield for Multiplatforms (ISMP) launcher program returns control to the command line or calling BAT script right away on Windows systems.

    If a BAT script has the following two lines, the second line runs before the Update Installer has completed the first line.

    "C:\IBM\WebSphere\AppServer60\updateinstaller\update" -W maintenance.package="C:\IBM\WebSphere\AppServer\updateinstaller\maintenance\PK20028.pak" -silent

    "C:\IBM\WebSphere\AppServer60\updateinstaller\update" -W maintenance.package="C:\IBM\WebSphere\AppServer\updateinstaller\maintenance\PK20029.pak" -silent



    The resulting asynchronous return to the script causes multiple instances of the Update Installer to run, which is not allowed. Use the following procedure to avoid the problem:

    1. Use the XCOPY command to create the default clone location for the SDK and copy the product SDK from the installation root in one operation.

      Copy the contents of the install_root\java\jre directory to the install_root\updateinstaller\java directory, which is the default location when the Update Installer clones the SDK automatically.

      For example, use the following command when the installation root directory is the C:\IBM\WebSphere\AppServer60 directory.

      xcopy C:\IBM\WebSphere\AppServer60\java\jre\*.* C:\IBM\WebSphere\AppServer60\updateinstaller\java\*.* /S

    2. Edit the batch script to change each update command to issue the Java calls directly instead of through ISMP:

      "C:\IBM\WebSphere\AppServer60\updateinstaller\java\bin\java.exe" -cp update.jar -Xms48m -Xmx384m run -W maintenance.package="C:\IBM\WebSphere\AppServer60\updateinstaller\maintenance\PK20028.pak" -silent

      "C:\IBM\WebSphere\AppServer60\updateinstaller\java\bin\java.exe" -cp update.jar -Xms48m -Xmx384m run -W maintenance.package="C:\IBM\WebSphere\AppServer60\updateinstaller\maintenance\PK20029.pak" -silent



      The -Xms48m parameter and the -Xmx384m parameter are the minimum heap size and the maximum heap size, respectively.

      td>

    3. Run the batch file to install the maintenance packages.

    The reworked batch file avoids the ISMP asynchronous behavior by invoking the native Java process directly. Additional parameters are allowed at the end of each line, such as the -options parameter.


     



    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" >

  • Issue the following command from the script:

    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.


  • Issue the following command from the script:

    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.

    [HP-UX]This is a known problem on some HP-UX systems.

    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:

      install_root
        /updateinstaller
           /java
              /jre

      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.

      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:

      1. Copy the install_root/java/jre directory to the install_root/updateinstaller/java directory.
      2. Change directories to the install_root/updateinstaller directory.
      3. 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:

      Prerequisite checking has failed. Failure messages follow:

      Contrary to the message, no additional messages display.

      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: You 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:

      ./update -options responsefiles/uninstall.txt -silent

      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.

      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, you can work around the problem by copying the SDK yourself before launching the Update Installer. Use the following procedure:

      1. Copy the install_root/java/jre directory to the install_root/updateinstaller/java directory.
      2. Change directories to the install_root/updateinstaller directory.
      3. Start the installation with the following command:

        ./update -options responsefiles/uninstall.txt   \
                -silent                                \
                -is:javahome install_root/updateinstaller/java

        Or, you 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:

      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.


      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.

      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.


    • [Linux][UNIX] 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:

      ADMR0104E: The system is unable to read document
      cells/MyCell/nodes/mynode/ node-metadata.properties:
      java.io.IOException: No such file or directory

      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.

      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:

        chown -R wsdemo profile_root

        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.

        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.

      Failure: The JDK copy has failed

      The error causes the following entries in the log file and the trace file entries.

      Entries in the updatelog.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

      Entries in the upatetrace.txt file

      <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>

      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.

      Copy the product SDK to the install_root/updateinstaller/java/jre directory.

      1. Copy the install_root/java/jre directory to the install_root/updateinstaller/java directory.
      2. Change directories to the install_root/updateinstaller directory.
      3. 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.

      <message>
      Result of executing
      C:\WAS60GM\properties\version\update\config\install\
      updateProfileJdbcTemplates.ant was: false
      </message>

      Running the script does not harm profiles that are already updated.

      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

       



       

       

      WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
      IBM is a trademark of the IBM Corporation in the United States, other countries, or both.