IBM WebSphere Application Server family

Readme for the update installer application for Version 5.1


Note

Before using this information, be sure to read the general information under Notices.

Compilation date: June 30, 2004
Copyright International Business Machines Corporation 2004. All rights reserved.
US Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents

About this readme_updateinstaller document
Installing interim fixes, cumulative fixes, and fix packs
Using the update installer application to update an extended node
Using the update installer application to update a deployment manager node
Using the update installer to update a base node
updateSilent command
updateSilent examples for interim fixes
updateSilent examples for cumulative fixes and fix packs
updateWizard command
updateWizard examples for interim fixes
updateWizard examples for cumulative fixes and fix packs
Uninstalling interim fixes, cumulative fixes, and fix packs
Removing a fix from an extended node
Removing a fix from a Network Deployment node
Removing a fix from a base node
Product version and history information
versionInfo command
genVersionReport command
Notices
Trademarks and service marks

About this readme_updateinstaller document

This readme_updateinstaller document describes using the update installer application to install an interim fix, a cumulative fix, or a fix pack on the WebSphere Business Integration Server Foundation product, the Network Deployment product, or the base WebSphere Application Server product. You can use the procedure for updating the base product as a generic example for installing an interim fix, a cumulative fix, or a fix pack on the WebSphere Application Server - Express product, on the WebSphere Application Server clients, on Edge components, or on the Application Server Toolkit.

Each interim fix, cumulative fix, or fix pack has a unique download file for a particular WebSphere Application Server product. You cannot install the fix pack for the base product, for example, on a product for which it was not intended, such as the Network Deployment product. Nor can you install the fix pack for a Linux platform on a Windows platform, for example.

This readme file describes how to remove an interim fix, a cumulative fix, or a fix pack from a WebSphere Application Server product.

This readme file describes using the updateSilent and the updateWizard interfaces to the update installer application. This document also describes product version and history information that the WebSphere Application Server products maintain whenever you install or remove an interim fix, a cumulative fix, or a fix pack.

This readme file is compiled from information center articles that are available at the http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp Web address. The information center has many intertopic links that this book is not able to replicate in its subset of information. Although some effort was made to remove such links and replace them with pointers to information center articles, it is possible that some links were missed. Links to information center articles that are not in this PDF do not function properly. Links to articles that are within this document do work correctly.

Installing interim fixes, cumulative fixes, and fix packs

This topic describes how to use the update installer program to install interim fixes, cumulative fixes, and fix packs. The update installer program is also known as the updateInstaller program or the Update installation wizard.

IBM Support offers tutorials on various WebSphere Application Server installation topics. See WebSphere education on demand: Installation best practices tutorials for more information. One topic describes updating WebSphere Application Server products using the update installer program.

You cannot install product updates correctly without the proper authorizations. Use the update installer program as the root user on a Linux or UNIX platform, or as the administrator on a Windows platform.

Three different sites contain service for WebSphere Application Server products and features:

You must use the update installer program to install cumulative fixes and fix packs for the two features. The relationship among interim fixes, cumulative fixes, and fix packs is shown in the Cumulative Fix Strategy for WebSphere Application Server V5.0 and V5.1 Web page.

Fix packs are also known as fixpacks, FixPaks and program temporary fixes, or PTFs.

There are two interfaces to the update installer application, a wizard with a graphical interface, and a command-line, silent interface:

Both the updateSilent command and the updateWizard command call the update installer program to install and uninstall interim fixes, cumulative fixes, and fix packs for WebSphere Application Server products.

The update installer application can also uninstall interim fixes, cumulative fixes, and fix packs. See Uninstalling interim fixes, cumulative fixes, and fix packs for more information.

The following descriptions contain reference information about installing interim fixes, cumulative fixes, and fix packs on WebSphere Application Server products:

Installation roots
The variable install_root represents the root directory for WebSphere Application Server. By default, this varies per product and operating system:

Space requirements
Space requirements vary depending on what you are installing. The size of each download is available on the Support site. After unpacking the ZIP file you download, delete the ZIP file to free space.

For a fix pack, have approximately 400 MB of free space in the /tmp directory and another 400 MB in the file system that hosts the WebSphere Application Server image (typically /usr) on a UNIX-based platform, or approximately 800 MB of free space on the disk drive where you are installing on a Windows platform.

Interim fixes require much less space to install.

Space is also required for backup files in the install_root/properties/version/backup directory. When installing a fix pack the space required is typically about the same as the size of the fix pack, that is, between 50 MB and 300 MB, depending on the particular fix pack.

The update installer program checks for required space before it installs an interim fix, a cumulative fix, or a fix pack. Fixes require much less space to install than do cumulative fixes or fix packs. The space requirement varies per cumulative fix. For example, Cumulative Fix 3 for Version 5.1 (5.1.0.3) requires 248 MB in the /tmp directory and another 248 MB in the partition that contains the installation root directory. That is a total of 496 MB.

The system temporary directory is determined by the JVM and by the operating system. It is possible for the system temporary directory and the installation root directory to be on the same partition.

Older versions of the update installer, including the version current at the time that Cumulative Fix 3 was released, check for the total space requirement but report each requirement separately. Unfortunately, the messages are misleading. If you have 300 MB of free space on a partition but both the /tmp directory and the installation root are on the partition, you do not have enough space for both.

In this example, you have 300 MB when you need 496 MB in the partition. Each space checking message states that you do not have enough space and that 248 MB is required. 300 MB is more than 248 MB so the message is misleading. The message should state that you need 496 MB in the partition, 248 MB of which is for the /tmp directory. The second message should state that you need 496 MB in the partition, 248 MB of which is for the installation root requirement.

Command name
updateSilent.sh, updateSilent.bat, updateWizard.sh, and updateWizard.bat, command-line interfaces to the installer.jar file.
Prerequisite environment setting
The JAVA_HOME environment setting must point to the IBM SDK for WebSphere Application Server products. Source the appropriate command:
Download from
Download the updateInstaller.zip file from the WebSphere Application Server Support page at http://www-1.ibm.com/support/docview.wss?rs=180&tc=SSEQTP&uid=swg24007195. The files that comprise the ZIP file are also part of each fix pack ZIP file package. Fix packs are named according to the Application Server product, the fix pack sequence, and the operating system platform.

Interim fixes are named according to the tracking number used for the defect that the interim fix solves. For example, PQ81989 is an interim fix. See 1.3.1 Java SDK, Java Tech Edition for WebSphere Application Server V5 for an example of a download page for an interim fix.

Cumulative fixes use a naming scheme that identifies the product, the cumulative fix number, and the operating system. The following example shows names for Cumulative Fix 3 for V5.1:

Table 1. Cumulative Fix 3 names for WebSphere Application Server, Version 5.1
Operating system platform Cumulative Fix 3 ZIP file Cumulative Fix 3 ID Default repository in installation root directory
AIX was510_cf3_aix.zip was510_cf3_aix ../update/ fixpacks
Linux was510_cf3_linux.zip was510_cf3_linux
Linux for S/390 was510_cf3_linux390.zip was510_cf3_linux390
Solaris was510_cf3_solaris.zip was510_cf3_solaris
HP-UX was510_cf3_hpux.zip was510_cf3_hpux
Windows was510_cf3_win.zip was510_cf3_win ..\update\ fixpacks
Table 2. Cumulative Fix 3 names for WebSphere Application Server Network Deployment, Version 5.1
Operating system platform Cumulative Fix 3 ZIP file Cumulative Fix 3 ID Default repository in installation root directory
AIX was510_nd_cf3_aix.zip was510_nd_cf3_fp2_aix ../update/fixpacks
Linux was510_nd_cf3_linux.zip was510_nd_cf3_linux
Linux for S/390 was510_nd_cf3_linux390.zip was510_nd_cf3_linux390
Solaris was510_nd_cf3_solaris.zip was510_nd_cf3_solaris
HP-UX was510_nd_cf3_hpux.zip was510_nd_cf3_hpux
Windows platforms was510_nd_cf3_win.zip was510_nd_cf3_win ..\update\ fixpacks

See WebSphere Application Server 5.1 Cumulative Fix 3 for an example of a download page for a cumulative fix.

Fix packs use a naming scheme that identifies the product, the fix pack sequence number, and the operating system.

The names of the cumulative fixes that the WebSphere Business Integration Server Foundation product installs for the base product and for the Network Deployment products are shown in the following table:

Table 3. Cumulative Fix 2 names for WebSphere Application Server, Version 5.1
Operating system platform Cumulative Fix 2 ZIP file Cumulative Fix 2 ID Default repository in installation root directory
AIX was510_cf2_aix.zip was510_cf2_aix ../update/ fixpacks
Linux was510_cf2_linux.zip was510_cf2_linux
Linux for S/390 was510_cf2_linux390.zip was510_cf2_linux390
Solaris was510_cf2_solaris.zip was510_cf2_solaris
HP-UX was510_cf2_hpux.zip was510_cf2_hpux
Windows was510_cf2_win.zip was510_cf2_win ..\update\ fixpacks
Table 4. Cumulative Fix 2 names for WebSphere Application Server Network Deployment, Version 5.1
Operating system platform Cumulative Fix 2 ZIP file Cumulative Fix 2 ID Default repository in installation root directory
AIX was51_nd_cf2_aix.zip was51_nd_cf2_fp2_aix ../update/fixpacks
Linux was51_nd_cf2_linux.zip was51_nd_cf2_linux
Linux for S/390 was51_nd_cf2_linux390.zip was51_nd_cf2_linux390
Solaris was51_nd_cf2_solaris.zip was51_nd_cf2_solaris
HP-UX was51_nd_cf2_hpux.zip was51_nd_cf2_hpux
Windows platforms was51_nd_cf2_win.zip was51_nd_cf2_win ..\update\ fixpacks

The latest available fix pack is Fix Pack 1 for the WebSphere Application Server V5.1.0 family of products:

Table 5. Fix Pack 1 names for WebSphere Application Server, Version 5.1.0
Operating system platform Fix Pack 1 ZIP file Fix Pack 1 ID Default repository in installation root directory
AIX was51_fp1_aix.zip was51_fp1_aix ../update/ fixpacks
Linux was51_fp1_linux.zip was51_fp1_linux
Linux for S/390 was51_fp1_linux390.zip was51_fp1_linux390
Solaris was51_fp1_solaris.zip was51_fp1_solaris
HP-UX was51_fp1_hpux.zip was51_fp1_hpux
Windows was51_fp1_win.zip was51_fp1_win ..\update\ fixpacks
Table 6. Fix Pack 1 names for WebSphere Application Server Network Deployment, Version 5.1.0
Operating system platform Fix Pack 1 ZIP file Fix Pack 1 ID Default repository in installation root directory
AIX was51_nd_fp1_aix.zip was51_nd_fp1_aix ../update/fixpacks
Linux was51_nd_fp1_linux.zip was51_nd_fp1_linux
Linux for S/390 was51_nd_fp1_linux390.zip was51_nd_fp1_linux390
Solaris was51_nd_fp1_solaris.zip was51_nd_fp1_solaris
HP-UX was51_nd_fp1_hpux.zip was51_nd_fp1_hpux
Windows platforms was51_nd_fp1_win.zip was51_nd_fp1_win ..\update\ fixpacks
Table 7. Fix Pack 1 names for WebSphere Business Integration Server Foundation, Version 5.1.0
Operating system platform Fix Pack 1 ZIP file Fix Pack 1 ID Default repository in installation root directory
AIX wbisf51_fp1_aix.zip wbisf51_fp1_aix (to extend the base product) ../update/ fixpacks
wbisf51_nd_fp1_aix (to extend the Network Deployment product)
Linux wbisf51_fp1_linux.zip wbisf51_fp1_linux (base)
wbisf51_nd_fp1_linux (Network Deployment)
Linux for S/390 wbisf51_fp1_linux390.zip wbisf51_fp1_linux390 (base)
wbisf51_nd_fp1_linux390 (Network Deployment)
Solaris wbisf51_fp1_solaris.zip wbisf51_fp1_solaris (base)
wbisf51_nd_fp1_solaris (Network Deployment)
HP-UX wbisf51_fp1_hpux.zip wbisf51_fp1_hpux
wbisf51_nd_fp1_hpux (Network Deployment)
Windows platforms wbisf51_fp1_win.zip wbisf51_fp1_win (base) ..\update\ fixpacks
wbisf51_nd_fp1_win (Network Deployment)
Table 8. Fix Pack 1 names for WebSphere Application Server Express, Version 5.1.0
Operating system platform Fix Pack 1 ZIP file Fix Pack 1 ID Default repository in installation root directory
AIX was51_express_fp1_aix.zip was51_express_fp1_aix ../update/ fixpacks
Linux was51_express_fp1_linux.zip was51_express_fp1_linux
Linux for S/390 was51_express_fp1_linux390.zip was51_express_fp1_linux390
Solaris was51_express_fp1_solaris.zip was51_express_fp1_solaris
HP-UX was51_express_fp1_hpux.zip was51_express_fp1_hpux
Windows platforms was51_express_fp1_win.zip was51_express_fp1_win ..\update\ fixpacks
Table 9. Fix Pack 1 names for WebSphere Application Server, Version 5.1.0 Application Clients
Operating system platform Fix Pack 1 ZIP file Fix Pack 1 ID Default repository in installation root directory
AIX was51_client_fp1_aix.zip was51_client_fp1_aix ../update/fixpacks
Linux was51_client_fp1_linux.zip was51_client_fp1_linux
Linux for S/390 was51_client_fp1_linux390.zip was51_client_fp1_linux390
Solaris was51_client_fp1_solaris.zip was51_client_fp1_solaris
HP-UX was51_client_fp1_hpux.zip was51_client_fp1_hpux
Windows platforms was51_client_fp1_win.zip was51_client_fp1_win ..\update\fixpacks
Download to
Choose a directory for unpacking the update installer program or fix pack zip file that does not have a space in its name. For example, do not use the default installation root on a Windows platform because it is within the Program Files directory. On a Linux or UNIX-based platform, you can use the installation root directory.

Create the install_root/update directory or the no_spaces_path\update directory on Windows platforms. Unpacking a fix pack creates the ../update/fixpacks directory. Create another directory, ../update/fixes, for a repository of fixes you download. If you create the default subdirectories, you can accept default interim fix and fix pack file locations when using the updateWizard interface. Otherwise, you must browse to locate the fixes or fix packs you are installing or uninstalling.

Location of extfile.jar
WebSphere Application Server product install_root/update/lib (or no_spaces_path\update\lib for Windows platforms)
Location of installer.jar, updateSilent.sh/bat, and updateWizard.sh/bat
WebSphere Application Server product install_root/update (or no_spaces_path\update for Windows platforms)
Location of readme_ptf.html
WebSphere Application Server product install_root/update/docs (or no_spaces_path\update\docs for Windows platforms)
Location of interim fix Java archive (JAR) files
install_root/update/fixes (or no_spaces_path\update\fixes)
Location of cumulative fix and fix pack JAR files
install_root/update/fixpacks (or no_spaces_path\update\fixpacks)

This directory is automatically created by unpacking the fix pack in the ../update directory.

Files in updateInstaller.zip
Always use the updateSilent (or updateWizard) command file from the updateInstaller.zip or fix pack you download, to use the most recent version. A newer version can manage previously downloaded fixes and fix packs. Files in the updateInstaller.zip package (or the fix pack ZIP package) include: In addition to the listed files, the cumulative fix pack zip file or the fix pack zip file also has a JAR file, such as the was510_nd_cf3_win.jar file. Each JAR file includes a cumulative fix or a fix pack.
Location of log and backup files
The update installer program records processing results in log files in the install_root/logs/update directory. Backup files created during the installation of fixes and fix packs are in the install_root/properties/version/backup directory. The files are required to uninstall an interim fix or fix pack.
Syntax and panel examples
Using the updateWizard interface to work with interim fixes
See updateWizard examples for interim fixes for more information.
Using the updateWizard interface to work with cumulative fixes and fix packs
See updateWizard examples for cumulative fixes and fix packs for more information.
Using the updateSilent interface to work with interim fixes
See updateSilent examples for interim fixes for more information.
Using the updateSilent interface to work with cumulative fixes and fix packs
See updateSilent examples for cumulative fixes and fix packs for more information.
Overview of the installation procedure
To install an interim fix, create an update/fixes directory on your disk drive, download the interim fix and the update installer from the Support Web site, and use the update installer to install the interim fix.

To install a cumulative fix or fix pack, create the update directory on your disk drive if it does not already exist, download and unzip the cumulative fix or the fix pack from the Support Web site, and use the update installer to install the cumulative fix or fix pack. The ZIP file for the cumulative fix or the fix pack includes the following files:

Special rules for applying fixes within a cell
One requirement governs applying an interim fix or fix pack to a cell, to ensure the continued, smooth interaction of the various WebSphere Application Server nodes:

Requirement 1: The Network Deployment product must be at the highest fix level within the cell.

For example, you cannot use the addNode command to add a V5.1 base WebSphere Application Server node to a V5.0.2 deployment manager cell.

There is no limitation on the fix level of a base Application Server V5 node within its cell, if the fix level of the base node is the same as or lower than that of the deployment manager. There is also no limit on the number of different V5.x fix levels that can coexist or interoperate within a cell, so long as the fix level for each base node is the same as or lower than that of the deployment manager. Version 5.0.x base nodes can comprise V5.1 deployment manager cells.

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 an interim fix or fix pack.

You can also use the silent update installer application to:

Updating cluster members
Refer to the following tip for information about updating cluster members:
Table 10. Installation tip
Operating platform Tip
All platforms Updating all cluster members to the same fix level

Do not launch multiple copies of the update installer program at one time The update installer program cannot be launched concurrently with itself. Performing more than one update at the same time can lead to a failed or faulty installation.

See Uninstalling interim fixes, cumulative fixes, and fix packs for a description of how to remove an interim fix or fix pack from an entire cell, or from any part of the cell.

Installing a fix pack or cumulative fix uninstalls all interim fixes that were installed with the update installer. Interim fixes for the IBM HTTP Server feature and the embedded messaging feature cannot be removed. Some of the interim fixes that are uninstalled might have been released after the release of the cumulative fix or the fix pack. Reinstall such interim fixes to bring your system back to the previous interim fix level.

This procedure describes a scenario for updating an entire cell to the same fix pack level. According to the requirements, apply a fix pack to the deployment manager node first. You can then apply the fix pack to zero, one, or more of the base nodes. If you update a base node in a cluster, install the interim fix, cumulative fix pack, or fix pack to each node in the cluster.

  1. Use the Windows Services panel to stop all services for WebSphere Application Server processes. This includes services for the deployment manager (dmgr) server, Application Servers (such as server1), and WebSphere MQ queue managers.
  2. Stop all Java processes that use the IBM Software Developer Kit (SDK) that WebSphere Application Server provides. Before installing or uninstalling interim fixes, cumulative fixes, and fix packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WebSphere Application Server provides.

    WebSphere Application Server processes include:

    Stop all Java processes, if necessary, with the killall -9 java command or by using the task manager on a Windows platform. If you do install or uninstall an interim fix, a cumulative fix, or a fix pack while a WebSphere Application Server-related Java process runs, IBM does not guarantee that the product can continue to run successfully, or without error.

  3. Stop all WebSphere MQ processes on a Windows platform.
    1. Stop the WebSphere MQ queue manager process.
      endmqm queue_manager_ID
    2. Stop all WebSphere MQ network activity:
      net stop "IBM MQSeries" 
    3. Remove the WebSphere MQ tray icon if it is present on a Windows system. On a Windows platform, remove the WebSphere MQ tray icon if it is present. The WebSphere MQ tray icon in the lower right corner indicates that a WebSphere MQ process (amqmtbrn.exe) is running. Right click the tray icon and click Hide to remove it.
    4. Reboot to free locked GSkit-related files. If the fix that you are installing contains service for the GSkit component, it is possible that the operating system might have locked the file. You can manually stop any Windows services as described in the first step and reboot to free all files.
  4. Stop all WebSphere MQ processes on a Linux or a UNIX platform.
    1. Type dspmq to show the state of any queue managers.
    2. Type endmqm -i for each running queue manager.
    3. Type $ ipcs -a to check for any IPCs.
    4. Type $ ipcrm -[qms] [ID] to delete the IPCs.
    5. Type ps -eaf | grep mqm or ps -eaf | grep ^MQ* to search for mqm processes.
    6. Type kill -9 amq_pid_1 amq_pid_2 ... amq_pid_n to stop any MQ processes that are running.
  5. Verify that the required free space is available before beginning the installation. The space required for unpacking the ZIP file is about the same as the size of the fix pack. After unpacking the ZIP file, you can delete the ZIP file if necessary. After it is installed, the fix pack code generally increases the installation and run-time footprints by only a small amount.
  6. Install the interim fix, the cumulative fix, or the fix pack on an Enterprise node, as described in Using the update installer application to update an extended node.
  7. Install the interim fix, the cumulative fix, or the fix pack on a WebSphere Business Integration Server Foundation node, as described in Using the update installer application to update an extended node.
  8. Install the interim fix, the cumulative fix, or the fix pack on a deployment manager node, as described in Using the update installer application to update a deployment manager node.
  9. Install the interim fix, the cumulative fix, or the fix pack on a base node, as described in Using the update installer to update a base node.

You can successfully install interim fixes, cumulative fixes, and fix packs on WebSphere Application Server nodes.

Using the update installer application to update an extended node

This topic describes the proper procedure for using the update installer program to install interim fixes, cumulative fixes, and fix packs on an extended node.

If you have not already done so, read Installing interim fixes, cumulative fixes, and fix packs for an overview of installing service to WebSphere Application Server products.

The update installer program installs interim fixes, cumulative fixes, and fix packs on WebSphere Application Server products, which include WebSphere Business Integration Server Foundation. WebSphere Business Integration Server Foundation is also referred to as the Integration Server.

This topic describes using the update installer application to install an interim fix, a cumulative fix, or a fix pack for the WebSphere Business Integration Server Foundation product on any Application Server product node in an entire cell. It also describes how to install the fix for the Integration Server product on a stand-alone base Application Server node. According to the guidelines:

  1. Install a fix on the deployment manager.
  2. Install a fix on the Integration Server product that extends the deployment manager.
  3. Install a fix on zero, one, or more of the base nodes:
    1. Install a fix on the base product on the node.
    2. Install a fix on the Integration Server product that extends the base node.
  4. Uninstall a fix from the Integration Server product on each base node and from each base node in a cell before you uninstall the fix from the Integration Server product on the deployment manager node and from the deployment manager node.

  1. Stop the nodeagent process on each managed node in the cell with the stopNode command. Issue the stopNode command from the install_root/bin directory of each managed node. For example, issue the following command on a Linux platform:
    # ./stopNode.sh -user name -password password

    See stopNode command for more information about the command.

    Stop all WebSphere Application Server-related Java processes. On a Windows platform, you can use the task manager to stop Java processes. On a Linux or UNIX-based platform, use the kill command or the killall java -9 command to stop Java processes.

    Use the Windows Services panel to stop any Windows service for the nodeagent, and for any other WebSphere Application Server related services, including Application Server processes, the jmsserver process, IBM HTTP Server and WebSphere MQ queue managers.

    If you do not have a deployment manager node, skip to step 14.

  2. Stop the deployment manager process with the stopManager command. The dmgr Java process is the deployment manager process. Issue the stopManager command from the install_root/bin directory of the deployment manager node. For example, issue the following command on a Linux platform:
    # ./stopManager.sh -user name -password password

    See stopManager command for more information about the command.

  3. Create the install_root/update directory on the deployment manager node, if the directory does not already exist. Later, you will also launch the update installer from this directory. Launching the update installer is not supported from a read-only directory, or from a directory with spaces in its name.

    For example, create the /opt/WebSphere/DeploymentManager/update directory on a Linux platform.

    On a Windows platform, create the update directory in a path where none of the directory names includes a space in their names. For example, do not create the C:\Program Files\WebSphere\DeploymentManager\update directory because the Program Files directory has a space in its name.

    You can install a fix from the C:\WebSphere\update directory, for example, to the Network Deployment product in the default installation root directory, C:\Program Files\WebSphere\DeploymentManager. The target directory can have a space; the source directory cannot.

  4. Create the update/fixes repository if you are installing an interim fix. It is not necessary to create the fixpacks repository directory. Unpacking a cumulative fix or a fix pack creates the fixpacks directory if the directory does not already exist.
  5. Download the interim fix, the cumulative fix, or the fix pack.

    Download an interim fix from the Support page to the update/fixes directory. Download a fix pack to the updatedirectory.

  6. Unpack the interim fix, the cumulative fix, or the fix pack. Unpacking a cumulative fix or a fix pack automatically creates the fixpacks directory.
    Table 11. Installation tip
    Operating platform Tip
    Windows platforms Use another unzip product such as WINZIP, instead of the PKWARE pkunzip utility to unzip the product archive.
  7. Download the ZIP file for the current update installer and extract the update installer application to the update directory. You can use the update installer application that is packaged as part of a fix pack. Or, you can download the current version of the file even though you might have an update installer from the fix pack or from a previous fix installation. The Support page links to the current installer for the version of the product that you are updating.
  8. Verify that the unpacked files are owned by root on a Linux or UNIX-based platform.
    1. List the contents of the download directory. For example:

      # ls -al
      
      
      drwxr-xr-x    6 root     bin           512 Jul 21 08:50 was51fp1_linux

      The directory list in the preceding example shows a Fix Pack 1 file for V5.1 that is not owned by root.

    2. Change the ownership of any files not owned by root. You can change the ownership of all files in the download directory.

      For example:

      # chmod -R root:root * 
  9. Set up the Java environment for the update installer.

    Setting the JAVA_HOME environment variable

    Important:
    If the update installer can set the Java environment, this step is unnecessary. Otherwise, this is a required step.

    It is possible that the update installer cannot set the JAVA_HOME environment variable. If you receive a message that the update installer cannot set JAVA_HOME, or if you have set the JAVA_HOME variable to point to a non-WebSphere Application Server SDK, you must set the JAVA_HOME variable to a correct value.

    Set the environment variable yourself when there is a problem, or source the appropriate command script from the bin directory of the product installation root so that the variable points to an IBM SDK for a WebSphere Application Server product.

    If you use the same command window that you use to issue the stopNode command, the stopManager command, or the stopServer command, you have already sourced the setupCmdLine script and set the JAVA_HOME environment variable.

    Otherwise, use the following procedure to update the JAVA_HOME variable:

    1. Open a command-line window.
    2. Change directories to the bin directory of the installation root.
    3. Issue the command to set JAVA_HOME. Issue the appropriate command:
      • . install_root/bin/setupCmdLine.sh (source the command on UNIX platforms - There is a space between the period and the installation root directory.)
      • source install_root/bin/setupCmdLine.sh (source the command on Linux platforms )
      • install_root\bin\setupCmdLine.bat (Windows platforms only)
  10. Install the interim fix, cumulative fix, or fix pack on the deployment manager node.
    1. Use the updateWizard command or the updateSilent command to install the interim fix, cumulative fix, or fix pack on the deployment manager node. The choice is whether to use a wizard. For more information about using either command, see the following articles:

      For example, assume that you are installing Fix Pack 1 on Version 5.1.0.0. To install the was51_nd_fp1_win fix pack, use this updateSilent command:

      C:\WebSphere\DeploymentManager\update> updateSilent 
         -fixpack 
         -installDir "C:\Program Files\WebSphere\DeploymentManager" 
         -skipIHS 
         -fixpackDir "C:\WebSphere\DeploymentManager\update\fixpacks"
         -install 
         -fixpackID was51_nd_fp1_win

      This example skips applying any service that might be in the fix pack for the IBM HTTP Server feature or the embedded messaging feature.

      The command is shown on more than one line for clarity.

    2. Install the same level interim fix, cumulative fix, or fix pack on the Integration Server product that extends the network deployment node. After installing the interim fix, cumulative fix, or fix pack on the deployment manager node, apply the same level fix to the Integration Server product that extends the network deployment node.
  11. Bring the deployment manager node back online with the startManager command. Issue the startManager command from the install_root/bin directory of the deployment manager node. For example, issue the following command on a Linux platform:
    # ./startManager.sh

    See startManager command for more information about the command.

  12. Verify that the deployment manager node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack applied. There are several ways to verify the successful installation of an interim fix, a cumulative fix, or a fix pack:
  13. Restart the node agent of each base node with the startNode command. Restart the node agent on each managed node to let the node agent continue to communicate with the updated deployment manager node.

    You can restart all node agents, but you do not need to restart node agents on managed nodes that you intend to update with the interim fix, the cumulative fix, or the fix pack. The interim fix installation, the cumulative fix installation, and the fix pack installation each require you to stop and restart the node agent. You can simply restart the node agent at the appropriate time.

    Issue the startNode command from the install_root/bin directory of each base node. For example, issue the following command on a Linux platform:

    # ./startNode.sh

    See startNode command for more information about the command.

  14. Install the interim fix, the cumulative fix, or the fix pack on each base node that is managed by the deployment manager and that is a node to which you intend to apply the fix. See Using the update installer to update a base node for information about how to perform this step.
  15. Install the interim fix, the cumulative fix, or the fix pack on the Integration Server product of each base node. After installing the interim fix, the cumulative fix, or the fix pack to the base product, apply the same level fix to the Integration Server product that extends the base node.

    For example, to install the was51_pme_fp1_win fix pack to the Integration Server product, use the following updateSilent command:

    C:\WebSphere\AppServer\update> updateSilent 
       -fixpack 
       -installDir "C:\Program Files\WebSphere\AppServer" 
       -skipIHS 
       -fixpackDir "C:\WebSphere\AppServer\update\fixpacks"
       -install 
       -fixpackID wbisf51_fp1_win

    The command is shown on more than one line, for clarity.

  16. Restart each server on the node with the startServer command.
  17. Restart the node agent for the base node with the startNode command if the node is part of a cell.
  18. Verify that the base node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack installed.
  19. Specify that file sets on each base node match those on the deployment manager node.

    Ensure consistent configuration data across a cell. You can synchronize files on individual nodes or throughout your system. To synchronize files throughout the system, use the deployment manager administrative console page, System administration > Nodes > check_each_node_name > Full Resynchronization. You can use the administrative console page, System Administration > Node Agents > nodeagent > File Synchronization Service, to specify automatic synchronization every minute until all base node servers are brought online.

  20. Verify that all nodes are online and that the cell is functioning correctly.
  21. Restore your original file synchronization settings, if you changed them.

    The cell is now fully functional. All operations are available and functioning normally.

You can successfully install interim fixes, cumulative fixes, and fix packs on Integration Server-extended nodes.

Using the update installer application to update a deployment manager node

This topic describes how to use the update installer program to install interim fixes, cumulative fixes, and fix packs on a deployment manager node.

If you have not already done so, read Installing interim fixes, cumulative fixes, and fix packs for an overview of installing service to WebSphere Application Server products. Update the deployment manager node before updating managed base nodes, which are base nodes that you have federated into the cell.

If you extended the deployment manager by installing the WebSphere Business Integration Server Foundation product, see Using the update installer application to update an extended node.

This topic describes the proper procedure for installing an interim fix, a cumulative fix or a fix pack in a Network Deployment, V5.x environment, using the update installer application.

  1. Stop the nodeagent process on each managed node in the cell with the stopNode command. Issue the stopNode command from the install_root/bin directory of each managed node. For example, issue the following command on a Linux platform:
    # ./stopNode.sh -user name -password password

    See stopNode command for more information about the command.

    Use the Windows Services panel to stop any Windows service for the nodeagent, and for any other WebSphere Application Server related services, including Application Server processes, the jmsserver process, IBM HTTP Server and WebSphere MQ queue managers.

    Stop all Java processes on the node, if necessary.

  2. Stop the deployment manager process with the stopManager command. The dmgr Java process is the deployment manager process. Issue the stopManager command from the install_root/bin directory of the deployment manager node. For example, issue the following command on a Linux platform:
    # ./stopManager.sh -user name -password password

    See stopManager command for more information about the command.

  3. Create the install_root/update directory on the deployment manager node, if the directory does not already exist. Later, you will also launch the update installer from this directory. Launching the update installer is not supported from a read-only directory, or from a directory with spaces in its name.

    For example, create the /opt/WebSphere/DeploymentManager/update directory on a Linux platform.

    On a Windows platform, create the update directory in a path where none of the directory names includes a space in their names. For example, do not create the C:\Program Files\WebSphere\DeploymentManager\update directory because the Program Files directory has a space in its name.

    You can install a fix from the C:\WebSphere\update directory, for example, to the Network Deployment product in the default installation root directory, C:\Program Files\WebSphere\DeploymentManager. The target directory can have a space; the source directory cannot.

  4. Create the update/fixes repository if you are installing an interim fix. It is not necessary to create the fixpacks repository directory. Unpacking a cumulative fix or a fix pack creates the fixpacks directory if the directory does not already exist.
  5. Download the interim fix, the cumulative fix, or the fix pack. Download an interim fix from the Support page to the update/fixes directory. Download a fix pack to the update directory.
  6. Unpack the interim fix, the cumulative fix, or the fix pack. Unpacking a cumulative fix or a fix pack automatically creates the fixpacks directory.
    Table 12. Installation tip
    Operating platform Tip
    Windows platforms Use another unzip product such as WINZIP, instead of the PKWARE pkunzip utility to unzip the product archive.
  7. Download the ZIP file for the current update installer and extract the update installer application to the update directory. You can use the update installer application that is packaged as part of a fix pack. Or, you can download the current version of the file even though you might have an update installer from the fix pack or from a previous fix installation. The Support page links to the current installer for the version of the product that you are updating.
  8. Verify that the unpacked files are owned by root on a Linux or UNIX-based platform.
    1. List the contents of the download directory. For example:

      # ls -al
      
      
      drwxr-xr-x    6 root     bin           512 Jul 21 08:50 was51fp1_linux

      The directory list in the preceding example shows a Fix Pack 1 file for V5.1 that is not owned by root.

    2. Change the ownership of any files not owned by root. You can change the ownership of all files in the download directory.

      For example:

      # chmod -R root:root * 
  9. Set up the Java environment for the update installer.

    Setting the JAVA_HOME environment variable

    Important:
    If the update installer can set the Java environment, this step is unnecessary. Otherwise, this is a required step.

    It is possible that the update installer cannot set the JAVA_HOME environment variable. If you receive a message that the update installer cannot set JAVA_HOME, or if you have set the JAVA_HOME variable to point to a non-WebSphere Application Server SDK, you must set the JAVA_HOME variable to a correct value.

    Set the environment variable yourself when there is a problem, or source the appropriate command script from the bin directory of the product installation root so that the variable points to an IBM SDK for a WebSphere Application Server product.

    If you use the same command window that you use to issue the stopNode command, the stopManager command, or the stopServer command, you have already sourced the setupCmdLine script and set the JAVA_HOME environment variable.

    Otherwise, use the following procedure to update the JAVA_HOME variable:

    1. Open a command-line window.
    2. Change directories to the bin directory of the installation root.
    3. Issue the command to set JAVA_HOME. Issue the appropriate command:
      • . install_root/bin/setupCmdLine.sh (source the command on UNIX platforms - There is a space between the period and the installation root directory.)
      • source install_root/bin/setupCmdLine.sh (source the command on Linux platforms )
      • install_root\bin\setupCmdLine.bat (Windows platforms only)
  10. Install the interim fix, cumulative fix, or fix pack on the deployment manager node.

    Use the updateWizard command or the updateSilent command to install the interim fix, cumulative fix, or fix pack on the deployment manager node. The choice is whether to use a wizard. For more information about using either command, see the following articles:

    For example, assume that you are installing Fix Pack 1 on Version 5.1.0.0. To install the was51_nd_fp1_win fix pack, use this updateSilent command:

    C:\WebSphere\DeploymentManager\update> updateSilent 
       -fixpack 
       -installDir "C:\Program Files\WebSphere\DeploymentManager" 
       -skipIHS 
       -fixpackDir "C:\WebSphere\DeploymentManager\update\fixpacks"
       -install 
       -fixpackID was51_nd_fp1_win

    This example skips applying any service that might be in the fix pack for the IBM HTTP Server feature or the embedded messaging feature.

    The command is shown on more than one line for clarity.

  11. Bring the deployment manager node back online with the startManager command. Issue the startManager command from the install_root/bin directory of the deployment manager node. For example, issue the following command on a Linux platform:
    # ./startManager.sh 

    See startManager command for more information about the command.

  12. Verify that the deployment manager node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack applied. There are several ways to verify the successful application of an interim fix, a cumulative fix, or a fix pack:
  13. Restart the node agent of each base node with the startNode command. Restart the node agent on each managed node to let the node agent continue to communicate with the updated deployment manager node.

    You can restart all node agents, but you do not need to restart node agents on managed nodes that you intend to update with the interim fix, the cumulative fix, or the fix pack. The interim fix installation, the cumulative fix installation, and the fix pack installation each require you to stop and restart the node agent. You can simply restart the node agent at the appropriate time.

    Issue the startNode command from the install_root/bin directory of each base node. For example, issue the following command on a Linux platform:

    # ./startNode.sh

    See startNode command for more information about the command.

  14. Install the interim fix, the cumulative fix, or the fix pack on each base node that is managed by the deployment manager and that is a node to which you intend to apply the fix. See Using the update installer to update a base node for information about how to perform this step.
  15. Restart each server on the node with the startServer command.
  16. Restart the node agent for the base node with the startNode command if the node is part of the cell.
  17. Verify that the base node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack installed.
  18. Specify that file sets on each base node match those on the deployment manager node. Ensure consistent configuration data across a cell. You can synchronize files on individual nodes or throughout your system.

    To synchronize files throughout the system, use the deployment manager administrative console page, System administration > Nodes > check_each_node_name > Full Resynchronization. You can use the administrative console page, System Administration > Node Agents > nodeagent > File Synchronization Service to specify automatic synchronization every minute until all base node servers are brought online.

  19. Verify that all nodes are online and that the cell is functioning correctly.
  20. Restore your original file synchronization settings, if you changed them. If all operations are available and functioning normally, the cell is now fully functional.

You can successfully install interim fixes, cumulative fixes, and fix packs to any node in the deployment manager cell.

Using the update installer to update a base node

This topic describes how to use the update installer program to install interim fixes, cumulative fixes, and fix packs on a base WebSphere Application Server node.

If you have not already done so, read Installing interim fixes, cumulative fixes, and fix packs for an overview of installing service to WebSphere Application Server products. You must update the deployment manager node before updating managed base nodes, which are base nodes that you have federated into a deployment manager cell.

If you extended the Application Server node by installing the WebSphere Business Integration Server Foundation product, see Using the update installer application to update an extended node.

Install the interim fix, the cumulative fix, or the fix pack on each base node to which you intend to apply the fix using the following procedure for each node.

  1. Install the interim fix, the cumulative fix, or the fix pack on the deployment manager node first if the base node is part of a cell, as described in Using the update installer application to update a deployment manager node. The deployment manager node must have the highest fix level within the cell.
  2. Stop the nodeagent process on a managed base node with the stopNode command if the node is part of a cell and if you have not already done so. Issue the stopNode command from the install_root/bin directory of each managed node. For example, issue the following command on a Linux platform:
    # ./stopNode.sh -user name -password password

    See stopNode command for more information about the command.

  3. Stop each server process on the base WebSphere Application Server node with the stopServer command. Issue the stopServer command from the install_root/bin directory of each managed node. For example, issue the following command on a Linux platform:
    # ./stopServer.sh server1 -user name -password password

    See stopServer command for more information about the command.

    Stop all WebSphere Application Server-related Java processes. On a Windows platform, you can use the task manager to stop Java processes. On a Linux or UNIX-based platform, use the kill command or the killall java -9 command to stop Java processes.

    Use the Windows Services panel to stop any Windows service for the nodeagent, and for any other WebSphere Application Server related services, including Application Server processes, the jmsserver process, IBM HTTP Server and WebSphere MQ queue managers.

  4. Create the install_root/update directory on the Application Server node, if the directory does not already exist. Later, you will also launch the update installer from this directory. Launching the update installer is not supported from a read-only directory, or from a directory with spaces in its name.

    For example, create the /opt/WebSphere/AppServer/update directory on a Linux platform.

    On a Windows platform, create the update directory in a path where none of the directory names includes a space in their names. For example, do not create the C:\Program Files\WebSphere\AppServer\update directory because the Program Files directory has a space in its name.

    You can install a fix from the C:\WebSphere\update directory, for example, to the Application Server product in the default installation root directory, C:\Program Files\WebSphere\AppServer. The target directory can have a space; the source directory cannot.

  5. Create the update/fixes repository if you are installing an interim fix. It is not necessary to create the fixpacks repository directory. Unpacking a cumulative fix or a fix pack creates the fixpacks directory if the directory does not already exist.
  6. Download the interim fix, the cumulative fix, or the fix pack. Download an interim fix from the Support page to the update/fixes directory. Download a fix pack to the update directory.
  7. Unpack the interim fix, the cumulative fix, or the fix pack. Unpacking a cumulative fix or a fix pack automatically creates the fixpacks directory.
    Table 13. Installation tip
    Operating platform Tip
    Windows platforms Use another unzip product such as WINZIP, instead of the PKWARE pkunzip utility to unzip the product archive.
  8. Download the ZIP file for the current update installer and extract the update installer application to the update directory. You can use the update installer application that is packaged as part of a fix pack. Or, you can download the current version of the file even though you might have an update installer from the fix pack or from a previous fix installation. The Support page links to the current installer for the version of the product that you are updating.
  9. Verify that the unpacked files are owned by root on a Linux or UNIX-based platform.
    1. List the contents of the download directory. For example:

      # ls -al
      
      drwxr-xr-x    6 root     bin           512 Jul 21 08:50 was51fp1_linux

      The directory list in the preceding example shows a Fix Pack 1 file for V5.1 that is not owned by root.

    2. Change the ownership of any files not owned by root. You can change the ownership of all files in the download directory.

      For example:

      # chmod -R root:root * 
  10. Set up the Java environment for the update installer.

    Setting the JAVA_HOME environment variable

    Important:
    If the update installer can set the Java environment, this step is unnecessary. Otherwise, this is a required step.

    It is possible that the update installer cannot set the JAVA_HOME environment variable. If you receive a message that the update installer cannot set JAVA_HOME, or if you have set the JAVA_HOME variable to point to a non-WebSphere Application Server SDK, you must set the JAVA_HOME variable to a correct value.

    Set the environment variable yourself when there is a problem, or source the appropriate command script from the bin directory of the product installation root so that the variable points to an IBM SDK for a WebSphere Application Server product.

    If you use the same command window that you use to issue the stopNode command or the stopServer command, you have already sourced the setupCmdLine script and set the JAVA_HOME environment variable.

    Otherwise, use the following procedure to update the JAVA_HOME variable:

    1. Open a command-line window.
    2. Change directories to the bin directory of the installation root.
    3. Issue the command to set JAVA_HOME. Issue the appropriate command:
      • . install_root/bin/setupCmdLine.sh (source the command on UNIX platforms - There is a space between the period and the installation root directory.)
      • source install_root/bin/setupCmdLine.sh (source the command on Linux platforms )
      • install_root\bin\setupCmdLine.bat (Windows platforms only)
  11. Install the interim fix, cumulative fix, or fix pack on the base node.

    Use the updateWizard command or the updateSilent command to install the interim fix, cumulative fix, or fix pack on the Application Server node. The choice is whether to use a wizard. For more information about using either command, see the following articles:

    For example, assume that you are installing Fix Pack 1 on Version 5.1.0.0. To install the was51_nd_fp1_win fix pack, use this updateSilent command:

    C:\WebSphere\AppServer\update> updateSilent 
       -fixpack 
       -installDir "C:\Program Files\WebSphere\AppServer" 
       -skipIHS
       -skipMQ
       -fixpackDir "C:\WebSphere\AppServer\update\fixpacks"
       -install 
       -fixpackID was51_fp1_win

    This example skips applying any service that might be in the fix pack for the IBM HTTP Server feature or the embedded messaging feature.

    The command is shown on more than one line for clarity.

  12. Restart the node agent of the base node with the startNode command if the node is federated. Restart the node agent on each managed node to let the node agent continue to communicate with the updated deployment manager node.

    Issue the startNode command from the install_root/bin directory of each base node. For example, issue the following command on a Linux platform:

    # ./startNode.sh

    See startNode command for more information about the command.

  13. Restart each server on the base node with the startServer command. Issue the startServer command from the install_root/bin directory of each managed node. For example, issue the following command on a Linux platform:
    # ./startServer.sh server1

    See startServer command for more information about the command.

  14. Verify that the Application Server node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack applied. There are several ways to verify the successful application of an interim fix, a cumulative fix, or a fix pack:

You can successfully install interim fixes, cumulative fixes, and fix packs on a base node.

updateSilent command

The updateSilent command is the silent, command-line interface to the update installer program of the IBM WebSphere Application Server. You can also use a wizard interface to the update installer program, the updateWizard command. The update installer program is also known as the updateInstaller program or the Update installation wizard.

The update installer program installs interim fixes, cumulative fixes, and fix packs to WebSphere Application Server products.

The relationship among interim fixes, cumulative fixes, and fix packs is shown in the Cumulative Fix Strategy for WebSphere Application Server V5.0 and V5.1 Web page.

Overview

Both the updateSilent command and the updateWizard command call the update installer program to install and uninstall interim fixes, cumulative fixes, and fix packs for WebSphere Application Server products. This topic describes the silent interface to the update installer program and its command-line parameters.

Stop all Java processes on the machine that use the IBM Software Developer Kit (SDK) that WebSphere Application Server provides: Before installing or uninstalling interim fixes, cumulative fixes, and fix packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WebSphere Application Server provides. WebSphere Application Server processes include:

Stop all Java processes, if necessary. If you do install or uninstall an interim fix, a cumulative fix, or a fix pack while a WebSphere Application Server-related Java process runs, IBM does not guarantee that the product can continue to run successfully, or without error.

Remove the WebSphere MQ tray icon if present On a Windows platform, remove the WebSphere MQ tray icon if it is present. The WebSphere MQ tray icon in the lower right corner indicates that a WebSphere MQ process (amqmtbrn.exe) is running. Right click the tray icon and click Hide to remove it.

Do not launch multiple copies of the update installer program at one time The update installer program cannot be launched concurrently with itself. Performing more than one update at the same time can lead to a failed or faulty installation.

The following descriptions contain reference information about the command. See Installing interim fixes, cumulative fixes, and fix packs for more information about using the command.

Command name
updateSilent.sh and updateSilent.bat, command-line interface to the installer.jar file.
Related command
updateWizard.sh and updateWizard.bat, graphical interface to the installer.jar file.
Syntax and panel examples
Using the updateSilent interface to work with interim fixes
See updateSilent examples for interim fixes for more information.
Using the updateSilent interface to work with cumulative fixes and fix packs
See updateSilent examples for cumulative fixes and fix packs for more information.

updateSilent examples for interim fixes

The updateSilent command is the silent, command-line interface for the update installer program. This topic describes using the wizard to work with interim fixes.

The update installer program installs interim fixes, cumulative fixes, and fix packs to WebSphere Application Server products.

Three different Web sites contain interim fixes for WebSphere Application Server products and features. Three sites exist because two of the features of the base product have their own service and support sites.

You cannot install or uninstall interim fixes for either of the two features using the update installer program for WebSphere Application Server. See the following tips for more information:

Table 14. Installation tip
Operating platform Tip in Platform-specific tips for installing and migrating
All platforms
  • Installing interim fixes for the IBM HTTP Server feature and the embedded messaging feature
  • Uninstalling interim fixes for the IBM HTTP Server feature and the embedded messaging (WebSphere MQ) feature before installing cumulative fixes and fix packs to the features

You must use the update installer program to install cumulative fixes and fix packs for the two features. See updateSilent examples for cumulative fixes and fix packs for more information about using the update installer program to install cumulative fixes and fix packs.

Syntax examples

The updateSilent interface actually provides two functions. Depending upon the parameters you choose, the command performs the following functions:

The following examples describe various usage syntaxes. In each syntax example, optional parameters are enclosed by brackets ([]). Values that you must supply appear in italicized font. Choices are denoted by the pipe symbol (|).

Help

updateSilent  -help | -? | -usage

updateSilent  /help | /? | -usage (Windows platforms)

Syntax for using a properties file to supply values

updateSilent myProps.properties

Syntax for processing interim fixes

updateSilent -installDir "fully qualified product install_root"
   -fix
   -fixDir "fully qualified interim fix repository root, 
           usually install_root/update/fixes"
   -install | -uninstall | uninstallAll
   -fixes space-delimited list of fixes
   -fixJars space-delimited list of interim fix JAR files
   [-fixDetails]
   [-prereqOverride]
                  
             

Syntax for viewing installed interim fixes

updateSilent 
   -fix
   -installDir "fully qualified product install_root"

Syntax for viewing available interim fixes

updateSilent 
   -fix 
   -installDir "fully qualified product install_root"
   -fixDir "fully qualified interim fix repository root, 
                      usually install_root/update/fixes"

Parameters

Use the following parameters for the updateSilent command:

-?
Shows command usage.
/?
Shows command usage on Windows platforms only.
-fix
Interim fix only: Identifies the update as an interim fix update.
-fixDetails
Interim fix only: Displays interim fix detail information.
-fixDir
Interim fix only: Specifies the fully qualified directory where you download fixes. This directory is usually the install_root/update/fixes directory.
-fixes
Interim fix only: Specifies a list of space-delimited fixes to install or uninstall. Specify either the fixJars parameter or this parameter.
-fixJars
Interim fix only: Specifies a list of space-delimited interim fix JAR files to install or uninstall. Each JAR file has one or more fixes. Specify either the fixes parameter or this parameter.
-help
Shows command usage.
/help
Shows command usage on Windows platforms only.
-install
Installs the update type.
-installDir
Specifies the fully qualified installation root of the WebSphere Application Server product.
-prereqOverride
Interim fix only: Overrides any installation and uninstallation prerequisite checking. The update installer program does not log missing prerequisites.
<propertyFile>.properties
Specifies an externally supplied parameters file.

You can supply parameters in an external .properties file, rather than directly on the command line. There are some differences in the formats of parameters:

You can use the .properties file as a template.

For example, a sample.properties file for installing two fixes might look like this:

#Sample.properties
   #Sample parameters file to install fixes with details and prerequisite override
   fix=true
   install=true
   installDir=C:\\WebSphere\\AppServer
   fixDir=C:\\WebSphere\\AppServer\\update\\fixes
   fixes=Fix1,Fix2
   fixDetails=true
   prereqOverride=true
-uninstall
Uninstalls the identified interim fix, cumulative fix, or fix pack. You must uninstall all interim fixes, cumulative fixes, and fix packs before uninstalling a WebSphere Application Server product. However, if you are manually uninstalling all WebSphere Application Server products from the machine, it is not necessary to uninstall all interim fixes, cumulative fixes or fix packs. See Uninstalling manually for more information.
-uninstallAll
Uninstalls all applied interim fixes. This parameter does not uninstall fix packs.

If you installed interim fixes from the WebSphere MQ Web site, you must use the uninstaller from WebSphere MQ to uninstall interim fixes for the embedded messaging feature. For more information about managing interim fixes for the embedded messaging feature, see the WebSphere MQ Service download site.

If you installed interim fixes from the IBM HTTP Server Web site, you must use the uninstaller from IBM HTTP Server to uninstall interim fixes for the IBM HTTP Server feature. For more information about managing interim fixes for IBM HTTP Server, see the IBM Support site for IBM HTTP Server.

-usage
Shows command usage.

Examples overview

The following examples assume that:

Examples in this section include:

Most of the examples are split into more than one line, for ease of publication.

Getting help for the command

To get help for the updateSilent command:

C:\WebSphere\AppServer\update> updateSilent -help 

Using a parameter properties file

To use the myProps.properties file to supply parameter values for the updateSilent command:

C:\WebSphere\AppServer\update> updateSilent myProps.properties 

Installing interim fixes

To install a collection of interim fixes:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer"
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -install 
   -fixes Fix1 Fix2  

It is not possible to install interim fixes for these features:

For more information about managing interim fixes for IBM HTTP Server, see the IBM Support site for IBM HTTP Server. For more information about managing interim fixes for the embedded messaging feature, see the WebSphere MQ Service download site.

To install a collection of interim fixes, and display interim fix details:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -install 
   -fixes Fix1 Fix2 
   -fixDetails 

To install a collection of interim fixes, and override prerequisite checking:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -install 
   -fixes Fix1 Fix2 
   -prereqOverride

To install interim fixes from a Java archive (JAR) file:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -install 
   -fixJar Fix1

To install interim fixes from a Java archive (JAR) file, and display interim fix details:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -install 
   -fixJar Fix1 
   -fixDetails

To install interim fixes from a Java archive (JAR) file:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -install 
   -fixJar Fix1 
   -fixDetails

Uninstalling interim fixes

To uninstall a collection of interim fixes:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -uninstall 
   -fixes Fix1 Fix2  

It is not possible to uninstall interim fixes for these features:

For more information about managing interim fixes for IBM HTTP Server, see the IBM Support site for IBM HTTP Server. For more information about managing interim fixes for the embedded messaging feature, see the WebSphere MQ Service download site.

To uninstall a collection of interim fixes, and display details:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -uninstall 
   -fixes Fix1 Fix2 
   -fixDetails 

To uninstall a collection of interim fixes, and override prerequisite checking:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -uninstall 
   -fixes Fix1 Fix2 
   -prereqOverride

To uninstall interim fixes in a Java archive (JAR) file:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -uninstall 
   -fixJar Fix1

To uninstall interim fixes in a Java archive (JAR) file, and display details:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -uninstall 
   -fixJar Fix1 
   -fixDetails

To uninstall interim fixes in a Java archive (JAR) file:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
   -uninstall 
   -fixJar Fix1 
   -fixDetails

Viewing information about interim fixes

To view a list of installed interim fixes:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer" 
         

To view a list of interim fixes that are available in the repository:

C:\WebSphere\AppServer\update> updateSilent 
   -fix 
   -installDir "C:\WebSphere\AppServer"
   -fixDir "C:\WebSphere\AppServer\update\fixes" 
         

It is not possible to view information about interim fixes for the IBM HTTP Server feature or the embedded messaging feature. For more information about managing interim fixes for IBM HTTP Server, see the IBM Support site for IBM HTTP Server. For more information about managing interim fixes for the embedded messaging feature, see the WebSphere MQ Service download site.

updateSilent examples for cumulative fixes and fix packs

The updateSilent command is the silent, command-line interface for the update installer program. This topic describes using the wizard to work with cumulative fixes and fix packs.

The update installer program installs interim fixes, cumulative fixes, and fix packs to WebSphere Application Server products. See updateWizard examples for interim fixes for information about using the update silent interface to work with interim fixes.

The relationship among interim fixes, cumulative fixes, and fix packs is shown in the Cumulative Fix Strategy for WebSphere Application Server V5.0 and V5.1 Web page.

Syntax examples

The updateSilent interface actually provides two functions. Depending upon the parameters you choose, the command performs the following functions:

The following examples describe various usage syntaxes. In each syntax example, optional parameters are enclosed by brackets ([]). Values that you must supply appear in italicized font. Choices are denoted by the pipe symbol (|).

Help

updateSilent  -help | -? | -usage

updateSilent  /help | /? | -usage (Windows platforms)

Syntax for using a properties file to supply values

updateSilent myProps.properties

Syntax for processing cumulative fixes and fix packs

updateSilent -installDir "fully qualified product install_root"
   -fixpack
   -fixpackDir "fully qualified FixPack repository root, 
               usually install_root/update/fixpacks"
   -install | -uninstall
   -fixPackID fix pack ID
   [-skipIHS | [-ihsOnly] -ihsInstallDir fully qualified IBM HTTP Server root]
   [-skipMQ | -mqInstallDir embedded messaging feature root]
   [-includeOptional space-delimited list of components]
   [-fixpackDetails]

All other valid arguments are ignored, such as the prereqOverride argument, which is for interim fix processing only.

You do not need to supply the -mqInstallDir argument for AIX, Linux, and UNIX-based platforms. The install location is fixed on those operating platforms. Use the argument on Windows platforms. The default location on Windows platforms is the C:\Program Files\IBM\WebSphere MQ directory.

Syntax for viewing installed cumulative fixes and fix packs

updateSilent -fixpack
   -installDir "fully qualified product install_root"

Syntax for viewing available cumulative fixes and fix packs

updateSilent -fixpack
   -installDir "fully qualified product install_root"
   -fixpackDir "fully qualified fix pack repository root,
               usually install_root/update/fixpacks"

Parameters

Use the following parameters for the updateSilent command:

-?
Shows command usage.
/?
Shows command usage on Windows platforms only.
-fixpack
Fix pack only: Identifies the update as a fix pack update.
-fixpackDetails
Fix pack only: Displays fix pack detail information.
-fixpackDir
Fix pack only: Specifies the fully qualified directory where you download and unpack fix packs. By default, this directory is the install_root/update/fixpacks directory.
-fixpackID
Fix pack only: Specifies the ID of a fix pack to install or uninstall. The value you specify does not include the .jar extension. The value is not the fully qualified package file name, but is the name of the individual fix pack within the JAR file.

The current Application Server strategy for fix pack JAR files uses one JAR file per fix pack. The fix pack ID is the name of the JAR file before the .jar extension. For example:

-help
Shows command usage.
/help
Shows command usage on Windows platforms only.
-ihsInstallDir
Fix pack only: Specifies the fully qualified path of the IBM HTTP Server product, and applies any service for the IBM HTTP Server product that might exist in the fix pack.
-ihsOnly
Fix pack only: Skips the installation of all service but that for the IBM HTTP Server product, and applies any service for the IBM HTTP Server product that might exist in the fix pack. Requires the -ihsInstallDir parameter.
-includeOptional
Fix pack only: Specifies a space-delimited list of features. The installer program applies any service for the components, if present in the fix pack. Otherwise, the installer program does not apply the service.
-install
Installs the update type.
-installDir
Specifies the fully qualified installation root of the WebSphere Application Server product.
-mqInstallDir
Fix pack only: Specifies the fully qualified installation root of the embedded messaging feature, which is based on WebSphere MQ technology.
<propertyFile>.properties
Specifies an externally supplied parameters file.

You can supply parameters in an external .properties file, rather than directly on the command line. There are some differences in the formats of parameters:

You can use the .properties file as a template.

A sample.properties file for installing a fix pack might look like this:

# WAS502CF5.properties
# Param file to install WebSphere AppServer 5.0.2 cumulative fix 5
install=true
installDir=C:\\WebSphere\\AppServer
fixpack=true
fixpackDir=C:\\WebSphere\\AppServer\\update\\fixpacks
fixpackID=was502_cf5_win
fixpackDetails=true
skipIHS=true
skipMQ=true
-skipIHS
Fix pack only: Skips any optional service for the IBM HTTP Server product that might exist in the fix pack.

If you installed the IBM HTTP Server product as a feature, use the update installer program to update it with service in an interim fix or fix pack. Otherwise, you must download an updated IBM HTTP Server product from http://www-3.ibm.com/software/webservers/httpservers/ and install it into the same directory as your existing version, to update the existing installation. You can also uninstall the current version and install the downloaded version, to avoid any issues with migration.

You must update your configuration if you reinstall.

You must update your configuration if you reinstall. The process is described in the Manually configuring supported Web servers (tins_manualWebServer) topic in the information center for the base Application Server product.

-skipMQ
Fix pack only: Specifies no application of any optional service for the embedded messaging feature (which is based on the IBM WebSphere MQ product) that might exist in the fix pack.

Always apply any outstanding corrective service to the stand-alone IBM WebSphere MQ product if you have it, before using the WebSphere Application Server update installer program to update the embedded messaging feature with service in an interim fix or fix pack. You can skip the installation of service to the embedded messaging feature if you must install corrective service to the stand-alone IBM WebSphere MQ product.

-uninstall
Specifies to uninstall the identified interim fix, cumulative fix, or fix pack. You must uninstall all interim fixes, cumulative fixes, and fix packs before uninstalling a WebSphere Application Server product. However, if you are manually uninstalling all WebSphere Application Server products from the machine, it is not necessary to uninstall all interim fixes, cumulative fixes or fix packs. See Uninstalling manually for more information.
-usage
Shows command usage.

Examples overview

The following examples assume that:

Examples in this section include:

Most of the examples are split into more than one line, for ease of publication.

Getting help for the command

To get help for the updateSilent command:

C:\WebSphere\AppServer\update> updateSilent -help 

Using a parameter properties file

To use the myProps.properties file to supply parameter values for the updateSilent command:

C:\WebSphere\AppServer\update> updateSilent myProps.properties 

Installing cumulative fixes and fix packs

To install a fix pack:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -ihsInstallDir "C:\Program Files\IBMHttpServer" 
   -fixpackDir "C:\WebSphere\AppServer\update\fixpacks" 
   -install 
   -fixpackID was510_cf2_win 

To install a fix pack, and display fix pack details:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -ihsInstallDir "C:\IBMHttpServer" 
   -fixpackDir "C:\WebSphere\AppServer\update\fixpacks" 
   -install 
   -fixpackID was510_cf2_win 
   -fixpackDetails
          

To perform a partial installation of a fix pack, by choosing to skip the installation of optional service to the WebSphere Application Server embedded messaging feature, which is based on WebSphere MQ:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -fixpackDir "C:\WebSphere\AppServer\update\fixpacks"
   -ihsInstallDir "C:\Program Files\IBMHttpServer"
   -install
   -fixpackID was510_cf2_win
   -skipMQ

The fix pack status shows partial installation.

About installation status

An interim fix or a fix pack is a collection of updates to one or more product components. Depending on installed product components and on update installer program selections you make, the update installer program applies either a full or partial set of interim fix or fix pack updates to product components.

Installed status implies that the interim fix or fix pack has no more updates to product components that you can install.

Partially installed status implies that you have updated one or more product components, but the interim fix or fix pack has at least one more update you can apply to an installed product component. (There might be other updates to product components you never installed. These updates do not count in the status determination.)

Uninstalled status implies that you have not updated a single product component.

Examples of partially installed states: Several scenarios can lead to a partial installation of an interim fix or fix pack:

How to distinguish between a normal partially installed state and an installation failure

A partially installed state implies that some components on the system are at the level of the fix pack being applied. However, there might be some scenarios where the update installer program can report a partially installed state even if no components are at the newer level. A partially installed state does not imply a failed install. However, a failed install does result in a partially installed state.

To check for a failed install, open the master log file and search for errors. The update installer program outputs the name of the master log file at the start of the installation process. The file name matches this pattern: install_root/logs/update/time-stamp_was50_fpnumber_platform_selective-install.log

To perform a partial installation of a fix pack, by choosing to skip the installation of optional service to the IBM HTTP Server feature:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -fixpackDir "C:\WebSphere\AppServer\update\fixpacks" 
   -mqInstallDir "C:\WebSphere MQ"
   -install 
   -fixpackID was510_cf2_win 
   -skipIHS

The fix pack status shows partial installation.

To perform a partial installation of a fix pack, by choosing to skip the installation of optional service to both the embedded messaging feature and the IBM HTTP Server feature:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -fixpackDir "C:\WebSphere\AppServer\update\fixpacks" 
   -install 
   -fixpackID was510_cf2_win
   -skipIHS 
   -skipMQ

The fix pack status shows partial installation.

Uninstalling cumulative fixes and fix packs

To uninstall a fix pack:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -uninstall 
   -fixpackID was510_cf2_win

To uninstall a fix pack, and display fix pack details:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -uninstall 
   -fixpackID was510_cf2_win 
   -fixpackDetails

Viewing information about cumulative fixes and fix packs

To view a list of installed fix packs:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
          

To view a list of fix packs available in the repository for the base WebSphere Application Server product:

C:\WebSphere\AppServer\update> updateSilent 
   -fixpack 
   -installDir "C:\WebSphere\AppServer" 
   -fixpackDir "C:\WebSphere\AppServer\update\fixpacks" 

updateWizard command

The updateWizard command is the wizard interface to the IBM WebSphere Application Server update installer program. You can also use a silent, command-line interface to the update installer program, the updateSilent command. The update installer program is also known as the updateInstaller program or the Update installation wizard.

The update installer program installs interim fixes, cumulatives fixes, and fix packs to WebSphere Application Server products.

The relationship among interim fixes, cumulative fixes, and fix packs is shown in the Cumulative Fix Strategy for WebSphere Application Server V5.0 and V5.1 Web page.

Overview

Both the updateWizard command and the updateSilent command command call the update installer program to install and uninstall interim fixes, cumulative fixes, and fix packs for WebSphere Application Server products. This topic describes the wizard interface to the update installer command, and gives some information about its panels and fields.

Stop all Java processes on the machine that use the IBM Software Developer Kit (SDK) that WebSphere Application Server provides: Before installing or uninstalling interim fixes, cumulative fixes, and fix packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WebSphere Application Server provides. WebSphere Application Server processes include:

Stop all Java processes, if necessary. If you do install or uninstall an interim fix, a cumulative fix, or a fix pack while a WebSphere Application Server-related Java process runs, IBM does not guarantee that the product can continue to run successfully, or without error.

Remove the WebSphere MQ tray icon if present On a Windows platform, remove the WebSphere MQ tray icon if it is present. The WebSphere MQ tray icon in the lower right corner indicates that a WebSphere MQ process (amqmtbrn.exe) is running. Right click the tray icon and click Hide to remove it.

Do not launch multiple copies of the update installer program at one time The update installer program cannot be launched concurrently with itself. Performing more than one update at the same time can lead to a failed or faulty installation.

The following descriptions contain reference information about the command. See Installing interim fixes, cumulative fixes, and fix packs for more information about using the command.

Command name
updateWizard.sh and updateWizard.bat, graphical interface to the installer.jar file.
Related command
updateSilent.sh and updateSilent.bat, command-line interface to the installer.jar file.

See updateSilent command.

Location of the command
See Installing interim fixes, cumulative fixes, and fix packs for a list of product installation roots, fix pack space requirements and names, and other information that also applies when using the updateWizard command interface.
Syntax and panel examples
Using the updateWizard interface to work with interim fixes
See updateWizard examples for interim fixes for more information.
Using the updateWizard interface to work with cumulative fixes and fix packs
See updateWizard examples for cumulative fixes and fix packs for more information.

updateWizard examples for interim fixes

The updateWizard command starts the Update installer wizard. This topic describes using the wizard to work with interim fixes.

The update installer program installs interim fixes, cumulative fixes, and fix packs to WebSphere Application Server products.

Installing interim fixes for features that are products

Three different Web sites contain interim fixes for WebSphere Application Server products and features. Three sites exist because two of the features of the base product have their own service and support sites.

You cannot install or uninstall interim fixes for either of the two features using the update installer program for WebSphere Application Server. See the following tips for more information:

Table 15. Installation tip
Operating platform Tip in Platform-specific tips for installing and migrating
All platforms
  • Installing interim fixes for the IBM HTTP Server feature and the embedded messaging feature
  • Uninstalling interim fixes for the IBM HTTP Server feature and the embedded messaging (WebSphere MQ) feature before installing cumulative fixes and fix packs to the features

You must use the update installer program to install cumulative fixes and fix packs for the two features. See updateWizard examples for cumulative fixes and fix packs for information about using the update installer program to install cumulative fixes and fix packs.

Parameters

Apply zero, one, or more of these optional parameters in any order, by issuing the updateWizard command from the command line.

-dpInstall
Lets you install an interim fix when there are prerequisite check errors.

The default behavior of the update installer application prevents further action if prerequisites are missing.

-dpUninstall
Lets you uninstall an interim fix when there are prerequisite check errors.
-fixOnly
Installs or uninstalls only interim fixes. To install and uninstall interim fixes, the updateWizard command does not require a local copy of the IBM Developer Kit or the Java Runtime Environment (JRE) in a client environment. This option bypasses making a local copy of the IBM Developer Kit or the JRE.

The default action for the update installer program enables both installing and uninstalling interim fixes, cumulative fixes, and fix packs. The wizard installs a temporary version of one of the IBM products that WebSphere Application Server uses to support the Java 2 SDK on your operating system platform, such as the IBM Developer Kit for AIX, Java Technology Edition.

The updateWizard command copies the IBM Developer Kit from the JAVA_HOME directory to the directory where you are running the updateWizard command (usually install_root/update). If the IBM Developer Kit is already in the directory (for example, if you used the updateWizard command before), the updateWizard command does not make a new copy. The copy of the IBM Developer Kit remains in the directory until you remove it. The IBM Developer Kit requires approximately 43 MB of free space.

If you install on a client platform, where there is a JRE instead of the IBM Developer Kit, the updateWizard command copies the JRE to the install_root/update directory. The JRE requires about 18 MB of free space.

-usage
Displays a list of parameters and how to use them in the correct command syntax.

Syntax for starting the wizard

The updateWizard command (install_root/update/updateWizard.sh and install_root\update\updateWizard.bat) launches the wizard interface to the update installer application.

install_root/update/updateWizard.sh  (Linux and UNIX-based platforms)

install_root\update\updateWizard.bat (Windows platforms)

Syntax for displaying usage information

This command displays command syntax:

updateWizard -usage

Syntax for bypassing the local copy of the IBM Developer Kit

The following command bypasses making a local copy of the IBM Developer Kit. Installing and uninstalling interim fixes does not require the local copy.

updateWizard -fixOnly

Disabling prerequisite checking

Disabling prerequisite checking is recommended only as directed by IBM Support personnel. Disabling prerequisite checking can leave the installation in a non-valid state.

To disable prerequisite checking when installing interim fixes:

updateWizard -fixOnly -dpInstall

To disable prerequisite checking when uninstalling interim fixes:

updateWizard -fixOnly -dpUninstall

Panel descriptions

Panels in the wizard let you select installable interim fixes, view installed interim fixes, and view prerequisite interim fixes:

Welcome panel

Use this panel to view a welcome message that contains a brief summary of the update wizard interface, or to link to the WebSphere Application Server Support page. (This link is not available on some UNIX-based platforms.) You can also view relevant legal notices.

Product selection panel

Use this panel to select an installed WebSphere Application Server product. If the wizard cannot detect an installed product, specify the product location in the directory input field. After selecting a product, its directory location appears in the input field for verification purposes. To make corrections or enter another product location, click Specify product location.

Menu panel

Use this panel to install or uninstall interim fixes, or to install or uninstall cumulative fixes and fix packs. If you started the wizard in -fixOnly mode, cumulative fix and fix pack options are disabled.

Fix repository specifier panel

Use this panel to provide the interim fix repository location in a directory input field. Specify the directory location of the downloaded interim fix JAR files. The default location for the repository is the install_root/update/fixes directory.

Installable fix selection panel

Use this panel to select one or more installable fixes for installing. Installed fixes do not appear in the list. Only uninstalled fixes or partially-installed fixes appear. The list includes interim fix ID name, build date, and the current applied state (uninstalled or partially-installed). Click Details for detailed information about selected fixes. The window that appears contains build version information, a long description, and a list of installation prerequisites.

About installation status

An interim fix, a cumulative fix, or a fix pack is a collection of updates to one or more product components. Depending on installed product components and on update installer program selections you make, the update installer program applies either a full or partial set of interim fix, cumulative fix, or fix pack updates to product components.

Installed status implies that the interim fix, cumulative fix, or fix pack has no more updates to product components that you can install.

Partially installed status implies that you have updated one or more product components, but the interim fix, cumulative fix, or fix pack has at least one more update that you can apply to an installed product component. (Updates to product components that you never installed do not count in the status determination.)

Uninstalled status implies that you have not updated a single product component.

Examples of partially installed states: Several scenarios can lead to a partial installation of an interim fix, a cumulative fix, or a fix pack:

How to distinguish between a normal partially installed state and an installation failure

A partially installed state implies that some components on the system are at the level of the cumulative fix or fix pack being applied. However, there might be some scenarios where the update installer program can report a partially installed state even if no components are at the newer level. A partially installed state does not imply a failed install. However, a failed install does result in a partially installed state.

To check for a failed install, open the master log file and search for errors. The update installer program outputs the name of the master log file at the start of the installation process. The file name matches this pattern: install_root/logs/update/time-stamp_was50_fpnumber_platform_selective-install.log

Uninstallable fix selection panel

Use this panel to select one or more installed interim fixes for uninstalling. Available fixes do not appear in the list. Only installed fixes appear. The list includes interim fix ID name, build date, and the current applied state (installed). Click Details to obtain more detailed information about a selected fix. The window that appears contains build version information, a long description, and a list of installation prerequisites.

You must uninstall all interim fixes before uninstalling the base WebSphere Application Server product, the Network Deployment product, or the WebSphere Business Integration Server Foundation product.

Prerequisite check panel

Use this panel to view prerequisite information when a selected interim fix has prerequisite fixes that are not installed. You cannot click Next until you correct the problem. The -dpInstall and the -dpUninstall parameters can override this lock, to let you continue installing or uninstalling even though a prerequisite checking failure occurs.

Pre-installing and Pre-uninstalling summary panels

Pre-installing summary panel Use this panel to display a summary of interim fixes that are selected for installation, the WebSphere Application Server product each interim fix is for, and the directory where each interim fix is located.

Pre-uninstalling Summary panel Use this panel to display a summary of interim fixes that are selected for uninstalling, and the WebSphere Application Server product to which each interim fix is currently applied.

Installing and Uninstalling panel

Installation action Use this panel to view the progress of installing selected interim fixes. Click cancel to revert the installation. Once cancelled, a message confirms that installed fixes are being rolled back. A similar progress panel then appears, to monitor the progress of rolling back the installation of selected fixes.

Uninstalling action Use this panel to view the progress of uninstalling selected interim fixes.

Post installation summary and Post uninstalling summary panels

Post installation summary panel Use this panel to view the results of the installation. Depending on the result, this panel can display a success message, a failure message, or a canceled message. When the success message appears, the installation process is complete. Click Finish to exit the panel. You can go back and install additional fixes, which takes you to the Menu panel.

Post uninstalling summary panel Use this panel to view the results of the uninstall procedure. Depending on the result, this panel can display a success message, a failure message, or a canceled message. When the success message appears, the uninstall process is complete. Click Finish to exit the panel. You can go back and uninstall additional fixes, which takes you to the Menu panel.

updateWizard examples for cumulative fixes and fix packs

The updateWizard command starts the Update installer wizard. This topic describes using the wizard to work with cumulative fixes and fix packs.

The update installer program installs interim fixes, cumulative fixes, and fix packs to WebSphere Application Server products. See updateWizard examples for interim fixes for information about using the Update installer wizard to install interim fixes.

The relationship among interim fixes, cumulative fixes, and fix packs is shown in the Cumulative Fix Strategy for WebSphere Application Server V5.0 and V5.1 Web page.

Syntax for starting the wizard

The updateWizard command (install_root/update/updateWizard.sh and install_root\update\updateWizard.bat) launches the wizard interface to the update installer application.

install_root/update/updateWizard.sh  (Linux and UNIX-based platforms)

install_root\update\updateWizard.bat (Windows platforms)

Syntax for displaying usage information

This command displays command syntax:

updateWizard -usage

Panel descriptions

Panels in the wizard let you select installable interim fixes, cumulative fixes, and fix packs, view installed interim fixes, cumulative fixes, and fix packs, and view prerequisite fixes:

Welcome panel

Use this panel to view a welcome message that contains a brief summary of the update wizard interface, or to link to the WebSphere Application Server Support page. (This link is not available on some UNIX-based platforms.) You can also view relevant legal notices.

Product selection panel

Use this panel to select an installed WebSphere Application Server product. If the wizard cannot detect an installed product, specify the product location in the directory input field. After selecting a product, its directory location appears in the input field for verification purposes. To make corrections or enter another product location, click Specify product location.

Menu panel

Use this panel to install or uninstall cumulative fixes and fix packs.

Cumulative fix and fix pack repository specifier panel

Use this panel to provide the cumulative fix and fix pack repository location in a directory input field. The location should point to the directory where you unpacked downloaded fix pack JAR files. The default location for the repository is the install_root/update/fixpacks directory.

Cumulative fix and fix pack selection panel

Use this panel to select from a list of installable cumulative fixes and fix packs. The panel displays fix packs by ID name, with a radio button next to each for selecting a single cumulative fix or fix pack. Also displayed is the build date and current applied state (uninstalled or partially-installed) for each cumulative fix or fix pack. A cumulative fix or fix pack on this panel can be in a partially installed state. No installed cumulative fixes or fix packs appear in the list. Click Details for more information about a selected cumulative fix or fix pack. The window that appears contains build version information, a long description, installation prerequisites, and a list of included fixes.

About installation status

An interim fix, a cumulative fix, or a fix pack is a collection of updates to one or more product components. Depending on installed product components and on update installer program selections you make, the update installer program applies either a full or partial set of interim fix, cumulative fix, or fix pack updates to product components.

Installed status implies that the interim fix, cumulative fix, or fix pack has no more updates to product components that you can install.

Partially installed status implies that you have updated one or more product components, but the interim fix, cumulative fix, or fix pack has at least one more update that you can apply to an installed product component. (Updates to product components that you never installed do not count in the status determination.)

Uninstalled status implies that you have not updated a single product component.

Examples of partially installed states: Several scenarios can lead to a partial installation of an interim fix, a cumulative fix, or a fix pack:

How to distinguish between a normal partially installed state and an installation failure

A partially installed state implies that some components on the system are at the level of the cumulative fix or fix pack being applied. However, there might be some scenarios where the update installer program can report a partially installed state even if no components are at the newer level. A partially installed state does not imply a failed install. However, a failed install does result in a partially installed state.

To check for a failed install, open the master log file and search for errors. The update installer program outputs the name of the master log file at the start of the installation process. The file name matches this pattern: install_root/logs/update/time-stamp_was50_fpnumber_platform_selective-install.log

Cumulative fix or fix pack features selection panel

Use this panel to view a list of WebSphere Application Server features with optionally installable service in the selected cumulative fix or fix pack. Features that can appear include IBM HTTP Server and the embedded messaging feature, which is based on IBM WebSphere MQ technology. If a feature has required service, the feature appears in the list but is grayed out. If you do not install optional service for an installed feature, the cumulative fix or fix pack installs successfully as a partially installed fix pack, because there is service that you did not install.

If you installed the IBM HTTP Server product as a feature, use the update installer program to update it with service in a cumulative fix or a fix pack. You can install interim fixes from the IBM Support site for IBM HTTP Server. Otherwise, you must download an updated IBM HTTP Server product from http://www-3.ibm.com/software/webservers/httpservers/ and install it into the same directory as your existing version to update the existing installation. You can also uninstall the current version and install the downloaded version, to avoid any issues with migration.

You must update your configuration if you reinstall.

You must update your configuration if you reinstall. The process is described in the Manually configuring supported Web servers (tins_manualWebServer) topic in the base Application Server information center.

Always apply any outstanding corrective service to the stand-alone IBM WebSphere MQ product if you have it, before using the WebSphere Application Server update installer program to update the embedded messaging feature with service in an interim fix, a cumulative fix, or a fix pack. Do not select the installation of service to the embedded messaging feature if you must install corrective service to the stand-alone IBM WebSphere MQ product.

Pre-installing summary and Pre-uninstalling summary panels

Pre-installing summary panel Use this panel to display a summary of the cumulative fix or fix pack selected for installation, the WebSphere Application Server product that is the target for the cumulative fix or fix pack, and the directory where the cumulative fix or fix pack is located.

Pre-uninstalling summary panel Use this panel to display a summary of the cumulative fix or fix pack that you are uninstalling, the WebSphere Application Server product to which the cumulative fix or fix pack was applied, and the directory where the cumulative fix or fix pack is located.

Installing and Uninstalling panel

Installing action Use this panel to view the progress of installing the selected cumulative fix or fix pack. Click cancel to revert the installation. Once cancelled, a message confirms that the cumulative fix or fix pack is being rolled back. A similar progress panel then appears, to monitor the progress of rolling back the installation of the selected cumulative fix or fix pack.

Uninstalling action Use this panel to view the progress of uninstalling the selected cumulative fix or fix pack. There is no way to cancel the uninstall action.

You must uninstall all cumulative fix or fix pack before uninstalling the base WebSphere Application Server product, the Network Deployment product, or the WebSphere Business Integration Server Foundation product.

Post installation summary and Post uninstalling summary panels

Post installation summary panel Use this panel to view the results of the installation. Depending on the result, this panel can display a success message, a failure message, or a canceled message. When the success message appears, the installation process is complete. Click Finish to exit the panel. You can go back and install another cumulative fix or fix pack, which takes you to the Menu panel.

Post uninstalling summary panel Use this panel to view the results of the uninstall action. Depending on the result, this panel can display a success message, a failure message, or a canceled message. When the success message appears, the uninstall process is complete. Click Finish to exit the panel. You can go back and uninstall another cumulative fix or fix pack. Going back takes you to the Menu panel.

Uninstalling interim fixes, cumulative fixes, and fix packs

This topic describes the proper procedure for using the update installer application to uninstall an interim fix, a cumulative fix, or a fix pack. The update installer program is also known as the updateInstaller program or the Update installation wizard.

You cannot uninstall product updates correctly without the proper authorizations. Use the update installer program as the root user on a Linux or UNIX platform, or as the administrator on a Windows platform.

Fix packs are also known as fixpacks, FixPaks and program temporary fixes, or PTFs.

Removing an interim fix, a cumulative fix, or a fix pack requires setting the JAVA_HOME environment variable for the update installer. The update installer performs the task by running the setupCmdLine or setupClient command script. It is possible that the update installer cannot set the JAVA_HOME environment variable. If the update installer throws an error because it cannot set the Java environment, set the JAVA_HOME variable yourself. Then use the update installer to remove an interim fix, a cumulative fix, or a fix pack using either its wizard interface, the updateWizard command (see updateWizard command) or its silent, command-line interface, the updateSilent command (seeupdateSilent command).

The update installer application can also install interim fixes, cumulative fixes, and fix packs. SeeInstalling interim fixes, cumulative fixes, and fix packs.

Installation roots
The variable install_root represents the root directory for WebSphere Application Server. By default, this varies per product and operating system:

Command name
updateSilent.sh, updateSilent.bat, updateWixard.sh, and updateWizard.bat, command-line interfaces to the installer.jar file.
Prerequisite environment setting
The JAVA_HOME environment setting must point to the IBM SDK for WebSphere Application Server products. Source the appropriate command:
Location of log and backup files
The update installer program records processing results in log files in the install_root/logs/update directory. Backup files created during the installation of fixes and fix packs are in the install_root/properties/version/backup directory. The files are required to uninstall an interim fix or fix pack.
Syntax and panel examples
Using the updateWizard interface to remove interim fixes
See updateWizard examples for interim fixes for more information.
Using the updateWizard interface to remove cumulative fixes and fix packs
See updateWizard examples for cumulative fixes and fix packs for more information.
Using the updateSilent interface to remove interim fixes
See updateSilent examples for interim fixes for more information.
Using the updateSilent interface to remove cumulative fixes and fix packs
See updateSilent examples for cumulative fixes and fix packs for more information.
Overview of the removal procedure
Use the update installer to uninstall a cumulative fix or a fix pack.

Use the update installer to uninstall an interim fix that you installed with the update installer.

If you have installed interim fixes for the IBM HTTP Server feature from the IBM Support site for IBM HTTP Server, or if you have installed interim fixes for the embedded messaging feature from the WebSphere MQ Service download site, the update installer program cannot uninstall interim fixes for these feature components before installing a cumulative fix or a fix pack that might include service for the features. The update installer program does uninstall interim fixes for all of the other components. If the interim fixes for the IBM HTTP Server feature and the embedded messaging feature are not uninstalled for some reason, installing a cumulative fix or a fix pack to the IBM HTTP Server feature or to the embedded messaging feature might fail, or the updated features might fail when you begin using them.

If you reinstall all of the interim fixes for either feature that are more current than the cumulative fix or the fix pack, there is no problem.

You can also choose to have the update installer skip applying cumulative fix or fix pack updates to IBM HTTP Server or embedded messaging if you do not require the updates. You can skip these updates and still apply updates to the rest of the product.

Special rules for removing fixes within a cell
One requirement governs applying an interim fix or fix pack to a cell, to ensure the continued, smooth interaction of the various WebSphere Application Server nodes:

Requirement 1: The Network Deployment product must be at the highest fix level within the cell.

For example, you cannot use the addNode command to add a V5.1 base WebSphere Application Server node to a V5.0.2 deployment manager cell.

There is no limitation on the fix level of a base Application Server V5 node within its cell, if the fix level of the base node is the same as or lower than that of the deployment manager. There is also no limit on the number of different V5.x fix levels that can coexist or interoperate within a cell, so long as the fix level for each base node is the same as or lower than that of the deployment manager. Version 5.0.x base nodes can comprise V5.1 deployment manager cells.

According to the guidelines:

  1. Remove an interim fix, a cumulative fix, or a fix pack from all base nodes:
    1. Remove the interim fix, cumulative fix, or fix pack from the Integration Server product that extends the base node.
    2. Remove the interim fix, cumulative fix, or fix pack from the base product on the node.
  2. Remove the interim fix, cumulative fix, or fix pack from the Integration Server product that extends the deployment manager.
  3. Remove the interim fix, cumulative fix, or fix pack from the deployment manager.
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 an interim fix or fix pack.

You can also use the silent update installer application to:

Updating cluster members
Refer to the following tip for information about updating cluster members:
Table 16. Installation tip
Operating platform Tip
All platforms Updating all cluster members to the same service level
Although the tip is about installing interim fixes and fix packs, the same principle applies to uninstalling interim fixes and fix packs. All clusters must be at the same service level.
Avoiding application errors after uninstalling an interim fix, a cumulative fix, or a fix pack
Generally speaking, if an application uses functions that are provided by a particular fix and you remove the fix, the application can throw an error. If you remove a fix, retest your applications to verify that there are no errors. Redeploy any applications that throw an error because of the missing fix.

For example, suppose that you install Fix Pack 1 on Version 5.1.0 of the base Application Server product. You then use Web services to create a stock quote service, StockQuote. The wsdl2java utility when run in the deployer role creates a ServiceLocator class in the emitted code that extends the AgnosticService class. The AgnosticService class is new as of V5.1.1.

If you uninstall the fix pack, the application is using a new Web services class that V5.1.0 does not support. The application throws the following error:

java.lang.NoClassDefFoundError: 
   Error while defining class: 
   com.ibm.ws.wsfvt.test.stockquote.StockQuoteServiceLocator
   This error indicates that the class: 
   com.ibm.ws.webservices.multiprotocol.AgnosticService
   could not be located while defining the class: 
   com.ibm.ws.wsfvt.test.stockquote.StockQuoteServiceLocator

Redeploy the application on the V5.1.0 Application Server to emit code that does not use the new V5.1.1 Web services class.

Always uninstall the highest level interim fix, cumulative fix, or fix pack before uninstalling other interim fixes or fix packs.

  1. Stop all Java processes that use the IBM Software Developer Kit (SDK) that WebSphere Application Server provides. Before installing or uninstalling interim fixes, cumulative fixes, and fix packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WebSphere Application Server provides.

    WebSphere Application Server processes include:

    Stop all Java processes, if necessary, with the killall -9 java command or by using the task manager on a Windows platform. If you do install or uninstall an interim fix, a cumulative fix, or a fix pack while a WebSphere Application Server-related Java process runs, IBM does not guarantee that the product can continue to run successfully, or without error.

  2. Remove the WebSphere MQ tray icon if it is present on a Windows system. On a Windows platform, remove the WebSphere MQ tray icon if it is present. The WebSphere MQ tray icon in the lower right corner indicates that a WebSphere MQ process (amqmtbrn.exe) is running. Right click the tray icon and click Hide to remove it.
  3. Remove the interim fix, the cumulative fix, or the fix pack from a WebSphere Business Integration Server Foundation node, as described in Removing a fix from an extended node.
  4. Remove the interim fix, the cumulative fix, or the fix pack from a deployment manager node, as described in Removing a fix from a Network Deployment node.
  5. Remove the interim fix, the cumulative fix, or the fix pack on a base node, as described in Removing a fix from a base node.

You can successfully remove interim fixes and fix packs from WebSphere Application Server products.

Removing a fix from an extended node

This topic describes the proper procedure for using the update installer application to remove an interim fix, a cumulative fix, or a fix pack from an extended node. The update installer program is also known as the updateInstaller program or the Update installation wizard.

The update installer program removes interim fixes, cumulative fixes, and fix packs from WebSphere Application Server nodes that are extended by the WebSphere Business Integration Server Foundation product.

See Installing interim fixes, cumulative fixes, and fix packs to install an interim fix, a cumulative fix, or a fix pack.

This procedure describes a scenario for removing an interim fix, a cumulative fix, or a fix pack from a base node, from an entire cell, or from any part of the cell in a WebSphere Business Integration Server Foundation environment.

According to the guidelines, uninstall the interim fix, cumulative fix, or fix pack from each base node in a cell before you uninstall the interim fix, cumulative fix, or fix pack from the deployment manager node.

When you install an interim fix, a cumulative fix, or a fix pack on an extended node, you actually install two fixes:

Remove the interim fix, cumulative fix, or fix pack from the Integration Server product when you remove it from the base or Network Deployment product.

Always uninstall the highest level interim fix, cumulative fix, or fix pack before uninstalling other interim fixes or fix packs.

  1. Stop all Java processes on the machine that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, as described in Uninstalling interim fixes, cumulative fixes, and fix packs.
  2. Remove the highest level interim fix, cumulative fix, or fix pack from the WebSphere Business Integration Server Foundation product on all base nodes where you are removing the fix, as described in Removing a fix from a base node. Simply select the WebSphere Business Integration Server Foundation interim fix, cumulative fix, or fix pack instead of the one for the base product. For example, remove the was51_pme_fp1_linux fix pack instead of the was51_fp1_linux fix pack.
  3. Remove the highest level interim fix, cumulative fix, or fix pack from all base nodes, as described in Removing a fix from a base node. If you remove the interim fix, cumulative fix, or fix pack from every base node in the cell, you can also remove the interim fix, cumulative fix, or fix pack from the Network Deployment node. The interim fix level of the Network Deployment node must be equal to, or higher than the interim fix level of any base node in the cell.
  4. Stop the deployment manager with the stopManager command. If you do not have a deployment manager node, you are finished with this procedure.
  5. Remove the highest level interim fix, cumulative fix, or fix pack from the WebSphere Business Integration Server Foundation product on the deployment manager node where you are removing the fix, as described in Removing a fix from a Network Deployment node. Simply select the WebSphere Business Integration Server Foundation interim fix, cumulative fix, or fix pack instead of the one for the deployment manager node. For example, remove the was51_pme_nd_fp1_linux fix pack instead of the was51_nd_fp1_linux fix pack.
  6. Remove the interim fix, cumulative fix, or fix pack from the deployment manager node, as described in Removing a fix from a Network Deployment node.
  7. Start the deployment manager node with the startManager command.
  8. Verify that the deployment manager node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack applied. There are several ways to verify the successful removal of an interim fix, a cumulative fix, or a fix pack:
  9. Specify that file sets on one node match those on the deployment manager node.

    Ensure consistent configuration data across a cell. You can synchronize files on individual nodes or throughout your system. To synchronize files throughout the system, use the deployment manager administrative console page, System administration > Nodes > check_each_node_name > Full Resynchronization. You can use the administrative console page, System Administration > Node Agents > nodeagent > File Synchronization Service, to specify automatic synchronization every minute until all base node servers are brought online.

  10. Verify that all nodes are online and that the cell is functioning correctly.
  11. Restore your original file synchronization settings. The cell is now fully functional. All operations are available and functioning normally.

You can successfully remove interim fixes and fix packs from extended nodes.

Removing a fix from a Network Deployment node

This topic describes the proper procedure for using the update installer application to uninstall an interim fix, a cumulative fix, or a fix pack on a deployment manager node. The update installer program is also known as the updateInstaller program or the Update installation wizard.

The update installer program uninstalls interim fixes, cumulatives fixes, and fix packs from WebSphere Application Server products. See Installing interim fixes, cumulative fixes, and fix packs to install an interim fix, a cumulative fix, or a fix pack.

This procedure describes a scenario for removing an interim fix, a cumulative fix, or a fix pack from an entire Network Deployment cell, or from any part of the cell. According to the guidelines, uninstall the interim fix, cumulative fix, or fix pack from each base node in a cell before you uninstall the interim fix, cumulative fix, or fix pack from the deployment manager node.

Always uninstall the highest level interim fix, cumulative fix, or fix pack before uninstalling other interim fixes or fix packs.

  1. Stop all Java processes on the machine that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, as described in Uninstalling interim fixes, cumulative fixes, and fix packs.
  2. Remove the highest level interim fix, cumulative fix, or fix pack from all base nodes, as described in Removing a fix from a base node. If you remove the interim fix, cumulative fix, or fix pack from every base node in the cell, you can also remove the interim fix, cumulative fix, or fix pack from the Network Deployment node. The interim fix level of the Network Deployment node must be equal to, or higher than the interim fix level of any base node in the cell.
  3. Stop the deployment manager with the stopManager command.
  4. Set up and configure your WebSphere Application Server environment. Set the JAVA_HOME environment variable for the update installer.

    Setting the JAVA_HOME environment variable

    Important:
    If the update installer can set the Java environment, this step is unnecessary. Otherwise, this is a required step.

    The location of the update, fixes, and fixpacks directories is arbitrary. You can create the directories anywhere so long as you do not use a directory name with one or more spaces.

    It is possible that the update installer cannot set the JAVA_HOME environment variable. If you receive a message that the update installer cannot set JAVA_HOME, set the environment variable yourself, or issue the appropriate command script from the bin directory of the product installation root:

    1. Open a command-line window.
    2. Change directories to the bin directory of the installation root.
    3. Run the appropriate command:
      • # . /setupCmdLine.sh (Source the command on UNIX platforms. There is a space between the period and the slash.)
      • # source setupCmdLine.sh (Source the command on Linux platforms.)
      • > setupCmdLine.bat (Windows platforms)
      • # . /setupClient.sh (Source the command for the Application Server client. There is a space between the period and the slash.)
      • # source setupClient.sh (Source the command on Linux platforms.)
      • > setupClient.bat (Windows platforms)
  5. Use the appropriate command to remove the interim fix, cumulative fix, or fix pack from the base node.

    Depending on the interface you use to the update installer:

    For example, to uninstall the was51_nd_fp1_win fix pack, use this updateSilent command:

    C:\WebSphere\AppServer\update> updateSilent -fixpack
           -installDir "C:\Program Files\WebSphere\AppServer"
           -skipIHS
           -fixpackDir "C:\WebSphere\AppServer\update\fixpacks"
           -uninstall
           -fixpackID was51_nd_fp1_win

    The command is shown here on more than one line, for clarity.

  6. Uninstall the Network Deployment product manually if you cannot successfully uninstall the interim fix, cumulative fix, or fix pack.

    The following platform-specific procedures for uninstalling each describe a manual process that guides you through removing every trace of the products and features you might have installed, including directories that might have changed data.

    Before you begin one of the procedures, back up the config and properties directories in the installation root. Backing up the directories lets you refer to the changed data when you reinstall.

  7. Start the deployment manager node with the startManager command.
  8. Verify that the deployment manager node is fully functional and that it has the interim fix, the cumulative fix, or the fix pack applied. There are several ways to verify the successful removal of an interim fix, a cumulative fix, or a fix pack:

    You can also run the installation verification tool on the node to verify that the node is operational. See Using the installation verification test for more information.

  9. Specify that file sets on one node match those on the deployment manager node.

    Ensure consistent configuration data across a cell. You can synchronize files on individual nodes or throughout your system. To synchronize files throughout the system, use the deployment manager administrative console page, System administration > Nodes > check_each_node_name > Full Resynchronization. You can use the administrative console page, System Administration > Node Agents > nodeagent > File Synchronization Service, to specify automatic synchronization every minute until all base node servers are brought online.

  10. Verify that all nodes are online and that the cell is functioning correctly.
  11. Restore your original file synchronization settings. The cell is now fully functional. All operations are available and functioning normally.

You can successfully remove interim fixes, cumulative fixes, and fix packs from a deployment manager node.

Removing a fix from a base node

This topic describes the proper procedure for using the update installer application to uninstall an interim fix, a cumulative fix, or a fix pack from an Application Server node. The update installer program is also known as the updateInstaller program or the Update installation wizard.

The update installer program removes interim fixes, cumulative fixes, and fix packs from WebSphere Application Server products, including base Application Server nodes.

See these information center topics:

This procedure describes a scenario for updating a base node by removing an interim fix, a cumulative fix, or a fix pack. See Installing interim fixes, cumulative fixes, and fix packs to install an interim fix, a cumulative fix, or a fix pack.

Always uninstall the highest level interim fix, cumulative fix, or fix pack before uninstalling other interim fixes or fix packs.

  1. Stop each server on the base node with the stopServer command.
  2. Set up and configure your WebSphere Application Server environment. Set the JAVA_HOME environment variable for the update installer. If the update installer can set the Java environment, this step is unnecessary. Otherwise, this is a required step.

    The location of the update, fixes, and fixpacks directories is arbitrary. You can create the directories anywhere so long as you do not use a directory name with a space in the name.

    The update installer can fail to set the JAVA_HOME environment variable. If you receive a message that the update installer cannot set JAVA_HOME or if you have previously set JAVA_HOME to a Java 2 SDK that is not the one that IBM ships with WebSphere Application Server, set the environment variable yourself or source the appropriate command script from the bin directory of the product installation root:

    1. Open a command-line window.
    2. Change directories to the bin directory of the installation root.
    3. Run the appropriate command:
      • # . /setupCmdLine.sh (Source the command on UNIX platforms. There is a space between the period and the slash.)
      • # source setupCmdLine.sh (Source the command on Linux platforms.)
      • > setupCmdLine.bat (Windows platforms)
      • # . /setupClient.sh (Source the command for the Application Server client. There is a space between the period and the slash.)
      • # source setupClient.sh (Source the command on Linux platforms.)
      • > setupClient.bat (Windows platforms)
  3. Use the appropriate command to remove the interim fix, cumulative fix, or fix pack from the base node.

    Depending on the interface you use to the update installer:

    For example, to uninstall the was51_fp1_win fix pack, use this updateSilent command:

    C:\WebSphere\AppServer\update> updateSilent -fixpack
           -installDir "C:\Program Files\WebSphere\AppServer"
           -skipIHS
           -fixpackDir "C:\WebSphere\AppServer\update\fixpacks"
           -uninstall
           -fixpackID was51_fp1_win

    The command is shown here on more than one line, for clarity.

  4. Restart each server on the node with the startServer command.
  5. Verify that the node is online and functioning correctly. There are several ways to verify the successful removal of an interim fix, a cumulative fix, or a fix pack:
  6. Uninstall the base product manually if you cannot successfully uninstall the interim fix, cumulative fix, or fix pack.

    The following platform-specific procedures for uninstalling each describe a manual process that guides you through removing every trace of the products and features you might have installed, including directories that might have changed data.

    Before you begin one of the procedures, back up the config and properties directories in the installation root. Backing up the directories lets you refer to the changed data when you reinstall.

You can successfully remove interim fixes, cumulative fixes, and fix packs from a base WebSphere Application Server node.

Product version and history information

The WebSphere Application Server product contains structural differences from previous versions. The /properties/version directory in the install_root contains important data about the product and its installed components, such as the build version and build date. This information is included in [product].product and [component].component files. The /properties/version/history directory in the install_root contains a collection of records for installed interim fixes and fix packs. This information is included in [interim fixID].efixApplied, [interim fixID].efixDriver, [fix packID].ptfApplied, and [fix packID].ptfDriver files. A driver file has useful information about the entire contents of an interim fix or fix pack. The applied file has relevant information about the interim fixes or fix packs that are currently applied. Event.history files are also present. They contain a detailed log about updates you have applied, either successfully or unsuccessfully. Time-stamped, detailed logs record each update process in the /properties/version/log directory of the install_root.

This topic describes the XML data files that store product information for Version 5 WebSphere Application Server products. By default, the document type declarations (DTDs) for these files are in the properties/version/dtd folder of the install_root, or the server root directory. See the Storage locations section for more information.

This topic includes these sections:

Product information files

XML files in the in the /properties/version directory that store version information:

platform.websphere
One file whose existence indicates that a WebSphere Application Server product is installed. An example of the file follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE websphere PUBLIC "websphereId" "websphere.dtd">
<websphere name="IBM WebSphere Application Server" version="5.0"/>

The following XML files in the /properties/version directory represent installed items and installation events.

product-id.product
One file whose existence indicates the particular WebSphere Application Server product that is installed. Data in the file indicates the version, build date, and build level. For example, the file might be the ND.product file, which indicates that the installed product is WebSphere Application Server Network Deployment. An example of the file follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE product PUBLIC "productId" "product.dtd">
<product name="IBM WebSphere Application Server for Network Deployment">
  <id>ND</id>
  <version>5.0.0</version>
  <build-info date="10/5/02" level="s0239.28"/>
</product>
component-name.component
Any number of component files that each indicate the presence of an installed component, which is part of the product. Data in the file indicates the component build date, build version, component name, and product version. For example, the file might be the activity.component file, which indicates that the activity component is installed. The activity component is part of the Network Deployment product. An example of the file follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE component PUBLIC "componentId" "component.dtd">
<component build-date="10/5/02" build-version="s0239.28" 
   name="activity" spec-version="5.0"/>
extension.id.extension
Any number of extension files that each indicate the presence of an extension that you install as a user extension, as part of a service engagement, or as installed by a third party product. The <extension.id>.extension files are not created, logged, or removed by WebSphere Application Server products.
fix-id.efix
Any number of interim fix files that each indicate the presence of an installed fix.
ptf-id.ptf
Any number of files, that each indicate the presence of an installed fix pack.

XML files in the /properties/version/history directory that store version history information files:

event.history
One file that lists update events that have occurred. An update event is an operation that installs or uninstalls an interim fix or a fix pack. The file is sorted by the date and time of the events that are listed.

The following XML files in the /properties/version/history directory describe fixes and fix packs that are currently installed. These XML files are related to installation items by the primary ID information, which is shown in the following examples as italicized text.

fix-id.efixDriver
Interim fix-driver defining information
fix-id.efixApplied
Interim fix installation details
ptf-id.ptfDriver
Fix pack-driver defining information
ptf-id.ptfApplied
Fix pack installation details

Reports

You can view product information by examining files in the properties/version directory, including the properties/version/history directory.

WebSphere Application Server provides the ability to generate two types of reports about the data in the files, Version reports and History reports. The following report-generation scripts are available in the install_root bin directory.

Product version reports

The following report generation scripts extract data from XML data files in the properties/version folder:

Product history reports

The following report generation scripts extract data from XML data files in the properties/version/history folder.

historyInfo.bat
Lets you use parameters to create a history report of installed and uninstalled fixes and fix packs, on Windows platforms. You can also specify a component name to create a report that shows the history for that component.

Parameters:

-format
text | html

Selects the format of the report. The default is TEXT.

-file
fileName

Specifies the output file name. The report goes to standard output (stdout) by default.

-updateID ID
Specifies the ID of an interim fix or fix pack update. When specified, the product history report displays events for only the specified update. When not specified, the report displays events for all updates.
-component componentName
Specifies the name of a component. When specified, the product history report displays events for only the named component. When not specified, the report displays events for all components.
historyInfo.sh
Lets you use parameters to create a history report on UNIX-based platforms. Parameters are the same as for the Windows version.
genHistoryReport.bat
Generates the historyReport.html report file in the bin directory on Windows platforms. The report includes all updates and components.
genHistoryReport.sh
Generates the historyReport.html report file in the bin directory on UNIX-based platforms. The report includes all updates and components.

Logs and component backups

WebSphere Application Server products use two other directories when performing update operations, for logging and backups:

install_root/properties/version/log
Product updates log directory prior to Fix Pack 2.

WebSphere Application Server products store log files to document component, interim fix and fix pack operations and updates.

install_root/logs/update
Product updates log directory beginning with Fix Pack 2.

Beginning with the version of the updateInstaller program that is bundled with Fix Pack 2, log files are in the install_root/logs/update directory.

install_root/properties/version/backup
Product updates backup directory

WebSphere Application Server products back up components before applying interim fixes and fix packs. If you uninstall an interim fix or fix pack, WebSphere Application Server products restore the backed-up component JAR file.

File naming convention

Time stamp
YYYYMMDD_HHMMSS

For example: 20020924_211832 is 24-Sep-2002, 9:18:32 pm, GMT. All time stamps are in GMT.

ID
Interim fix ID or fix pack ID

For example: apar6789c is an interim fix ID; PTF_1 is a fix pack ID.

Operation
install | uninstall
Interim fix log file names
timeStamp_fixId_operation.log

For example, prior to Fix Pack 2:properties/version/log/20020924_211832_apar6789c_install.log and properties/version/log/20020924_211912_apar6789c_uninstall.log

At Fix Pack 2 or later, the updateInstaller creates these logs: install_root/logs/update/20020924_211832_apar6789c_install.log and install_root/logs/update/20020924_211912_apar6789c_uninstall.log

Interim fix component log file names
timeStamp_fixId_componentName_operation.log

For example, prior to Fix Pack 2: properties/version/log/20020924_211832_apar6789c_ras_install.log and properties/version/log/20020924_211912_apar6789c_ras_uninstall.log

At Fix Pack 2 or later, the updateInstaller creates these logs: install_root/logs/update/20020924_211832_apar6789c_ras_install.log and install_root/logs/update/20020924_211912_apar6789c_ras_uninstall.log

Fix pack log file names
timeStamp_ptfId_operation.log

For example, prior to Fix Pack 2: properties/version/log/20030324_211832_was50_fp1_install.log and properties/version/log/20030325_211912_was50_fp1_uninstall.log

At Fix Pack 2 or later, the updateInstaller creates these logs: install_root/logs/update/20030324_211832_was50_fp2_install.log and install_root/logs/update/20030325_211912_was50_fp2_uninstall.log

Fix pack component log file names
timeStamp_ptfId_componentName_operation.log

For example, prior to Fix Pack 2: properties/version/log/20030324_211832_was50_fp1_ras_install.log and properties/version/log/20030325_211912_was50_fp1_ras_uninstall.log

At Fix Pack 2 or later, the updateInstaller creates these logs: install_root/logs/update/20030324_211832_was50_fp2_ras_install.log and install_root/logs/update/20030325_211912_was50_fp2_ras_uninstall.log

Backup JAR file names
timeStamp_ptfId_componentName_undo.jar or timeStamp_fixId_componentName_undo.jar

For example: 20020924_211832_apar6789c_ras_undo.jar

Do not delete a backup JAR file. You cannot remove a component update if the corresponding backup JAR file is not present.

Update processing might also use a temporary directory, if necessary. A Java property specifies this directory as described in the next section.

Storage locations

Product information files are located relative to the WebSphere Application Server product install_root, or the server root directory.

Default file paths are:

Version directory
install_root/properties/version or server_root/properties/version
History directory
install_root/properties/version/history
Updates log directory
Prior to Fix Pack 2:install_root/properties/version/log

The version of the updateInstaller that is bundled with Fix Pack 2 and later fix packs, stores log files in the install_root/logs/update directory.

Updates backup directory
install_root/properties/version/backup
DTD directory
install_root/properties/version/dtd
Temporary directory
Specified by the java.io.tmpdir Java system property

Operational description

WebSphere Application Server products update the product version history information while performing events that install or uninstall fixes or fix packs. Events that might occur include:

Data dictionary

Type Family: websphere product family

File Types:
websphere
File Type:
websphere
Elements:
name                  string     required
version               string     required
Persistence:
versionDir/platform.websphere

Type Detail:

The websphere file denotes the presence of WebSphere family products.

Element Detail:

websphere.name           The WebSphere product family name.
websphere.version        The WebSphere product family version.


Type Family:      product

File Types:       product
                  component
                  extension

File Type:        product

Persistence:      versionDir/id.product

Elements:         id                    string     required
                  name                  string     required
                  version               string     required
                  build-info            complex    required

Type Detail:

A product file is placed to denote the presence of a specific 
WebSphere family product.
The product ID is embedded in the product file name.

Element Detail:

product.id               The id of the product.
product.name             The name of the product.
product.version          The version of the product.
product.build-info       An element containing build information for
                         the product.

Element Type:     build-info

Elements:         date                  date       required
                  level                 string     required

Type Detail:

A build-info instance details the build of a specific installed 
WebSphere family product.

Element Detail:

build-info.date          The date on which the product was build.
build-info.level         The level code of the product's build.

File Type:        component

Persistence:      versionDir/name.component

Elements:         name                  string     required
                  spec-version          string     required
                  build-version         string     required
                  build-date            date       required

File Detail:

A component file denotes the presence of a specific component.  
The component name is embedded in the component file name.

Element Detail:

component.name           The name of the component.
component.spec-version   The specification version of the component.
component.build-version  The build level of the component.
component.build-date     The build date of the component.

File Type:        extension

Persistence:      versionDir/id.extension

Elements:         id                    string     required
                  name                  string     required

File Detail:

An extension file denotes the presence of a specific extension.  The
extension's id is embedded in the extension file name.

The elements of an extension file are minimally specified.  The listed
elements are required.  Additional elements may be present as determined
by the actual installed extension.

Element Detail:

extension.id             The id of the extension.
extension.name           The name of the extension.


Type Family:      update

File Types:       efix
                  ptf
                  efix-applied
                  ptf-applied

File Type:        efix

Persistence:      versionDir/id.efix

Elements:         id                    string     required
                  apar-number           string     optional
                  pmr-number            string     optional
                  short-description     string     required
                  long-description      string     required
                  is-temporary          boolean    required
                  build-version         string     required
                  build-date            date       required
                  component-update      complex    min=1, max=unbounded
                  platform-prereq       complex    min=0, max=unbounded
                  product-prereq        complex    min=0, max=unbounded
                  efix-prereq           complex    min=0, max=unbounded
                  custom-property       complex    min=0, max=unbounded

Type Detail:

An efix file denotes the presence of some portion of a specific fix.  
The ID of the interim fix is embedded in the file name.

An efix file contains all interim fix data, such as description, 
a listing of component updates, and prerequisite information.

Almost always, when installing a fix, all of the potential component
updates within the interim fix are required to be installed.

A separate application file must be examined to determine the components
which have been updated for a particular fix.

A list of custom properties may be provided.  These are provided for
future use.

Element Detail:

efix.id                  The id of the fix.

efix.short-description   A short description of the fix.

efix.long-description    A long description of the fix.

efix.is-trial            A flag indicating whether or not an interim fix is 
                         considered a trial fix.  Generally, a trial interim 
                         fix will be followed up with a more permanent fix.

efix.expiration-date     A date on which the interim fix is obsolete.

efix.build-version       The build version of the fix.  This is distinct from
                         the build version of component updates contained within
                         the fix.

efix-build-date          The build date of the fix.  This is distinct from the
                         build version of the component updates contained within
                         the fix.

efix.apar-info           A list of APAR's which are associated with the fix.

efix.component-update    A list of updates for components.  For a fix, these are
                         usually all required, and are all patch updates. At least
                         one component update must be present.

efix.efix-prereq         A list of prerequisite fixes for the fix. Note that
                         prerequisite fixes may be negative (see below). This
                         list may be (and is often) empty.

efix.plaform-prereq      A list of platforms on which the interim fix may be installed.
                         This list may be empty, in which case the interim fix may be
                         installed on all platforms.

efix.product-prereq      A list of products on which the interim fix may be installed.
                         This list may be empty, in which case the interim fix may be
                         installed on all products.

efix.custom-proprty      A list of properties, provided for future use.


File Type:        ptf

Persistence:      versionDir/id.ptf

Elements:         id                    string     required
                  short-description     string     required
                  long-description      string     required
                  build-version         string     required
                  build-date            date       required
                  component-update      complex    min=1, max=unbounded
                  product-update        complex    min=0, max=unbounded
                  platform-prereq       complex    min=0, max=unbounded
                  product-prereq        complex    min=0, max=unbounded
                  included-efix         complex    min=0, max=unbounded
                  custom-property       complex    min=0, max=unbounded

Type Detail:

A ptf file denotes the presence of some portion of a specific fix pack.  
The id of the fix pack is embedded in the fix pack file name.

A ptf file contains all fix pack data, such as description, a listing of 
component updates, and prerequisite information.

Usually, when installing a fix pack, you can omit certain potential component 
updates, but only when the corresponding component is not installed.

You must examine a separate application file, to determine which components
a particular fix pack has updated.

A fix pack can include updates for a number of fixes.

A list of custom properties might be provided. These are for future use.

Element Detail:

ptf.id                   The ID of the fix pack.

ptf.short-description    A short description of the fix pack.

ptf.long-description     A long description of the fix pack.

ptf.build-version        The build version of the fix pack.  
                         This is distinct from the build version of 
                         component updates contained within the fix pack.

ptf-build-date           The build date of the fix pack.  This is distinct 
                         from the build version of the component updates 
                         contained within the
                         fix pack.

ptf.component-update     A list of updates for components.  For a fix pack, 
                         these are usually all required, and are all patch updates.  
                         At least one component update must be present.

ptf.plaform-prereq       A list of platforms on which you can install the fix pack.  
                         This list might be empty. If so, you can install the fix 
                         pack on all platforms.

ptf.product-prereq       A list of products on which you can install the fix pack.  
                         This list might be empty. If so, you can install the fix 
                         pack on all products.

ptf.included-efix        A list of fixes which are included (fixed) by the fix pack.

ptf.custom-proprty       A list of properties, provided for future use.

Element Type:     component-update

Elements:         component-name        string     required
                  update-type           enum       required [enumUpdateType]
                  is-required           boolean    required
                  is-recommended        boolean    required
                  is-optional           boolean    required
                  is-external           boolean    required
                  root-property-file    anyURL     optional
                  root-property-name    string     optional
                  root-property-value   anyURL     optional
                  is-custom             boolean    required
                  primary-content       string     required
                  component-prereq      complex    min=0, max=unbounded
                  final-version         complex    optional
                  custom-property       complex    min=0, max=unbounded

Type Detail:

A component update represents a potential component update which is packaged
in an update (an interim fix or a fix pack).

An component update may be required, in which case the parent update may not
be installed unless the component update can be installed.  (A component update
can be installed if the corresponding component is installed.)

A component update may be a custom update, in which case the content which
was provided must be an executable file.  Otherwise, the content which is
provided must be an update JAR file.

A component update has a type.  A final version may be required according to
the update type.

Element Detail:

component-update.component-name   The name the component which is to be updated.

component-update.update-type      The type of the component update, one of 'add',
                                  'replace', 'remove', or 'patch'.  Final version
                                  information must be provided when the update type
                                  is 'add' or 'replace'.

component-update.is-required      A flag which, when true, specifies that the parent
                                  update may not be applied unless this component
                                  update is applied.

component-update.is-recommended   A flag which, when true, specifies that this
                                  component update, although optional, should be
                                  installed.

component-update.is-optional      A flag which, when true, specifies that this update
                                  may be omitted even if its corresponding component
                                  is installed.

component-update.is-external          A flag which, when true, specifies that this
                                      component update may live outside of the usual
                                      install root.


component-update.root-property-file   For a component with an external root, this
                                      properties file provides the root value.


component-update.root-property-name   For a component with an external root, 
                                      this named property provides the root value.


component-update.root-property-value  For a component with an external root, this value
                                      provides the default root value.


component-update.is-custom        A flag which, when true, specifies that the update
                                  is a custom update.  When true, the content must
                                  be an executable program.  When false, the content
                                  must be an update JAR.


component-update.primary-content  The name of the content which is provided for the
                                  update.  This will be an entry which is packaged
                                  in the 'components' directory of the update.


component-update.component-prereq A list of component versions, one of which must
                                  be present for this update to be installed.
                                  When this list is empty, any component version
                                  is allowed.


component-update.final-version    Final version information for the component.
                                  A final version is required when the update
                                  operation is 'add' or 'replace'.


component-update.custom-property  A list of properties, provided for future use.


Element Type:     apar-info

Elements:         number                string     required
                  date                  date       required
                  short-description     string     required
                  long-description      string     optional

Type Detail:

An apar-info object provides information about an APAR which is associated
with a fix, usually indicating that the interim fix provides an interim fix 
for the APAR.

Element Detail:

apar-info.number             The number of the associated APAR.

apar-info.date               The date of the APAR.

apar-info.short-description  A short description of the APAR.

apar-info.long-description   An optional long description of the APAR.

Element Type:     efix-prereq

Elements:         efix-id               string     required
                  is-negative           boolean    required
                  install-index         int        optional

Type Detail:

An efix-prereq instance denotes an interim fix that must be present 
(or, if negative, must be absent) for the parent interim fix to be installed.

efix-prereq instances can specify a cycle, in which case the prerequisite
specification is treated as a corequisite specification.

The following chart summarizes the interpretation of prerequisite information 
for two fixes:

       fix1       fix2
        -          -          Install the fixes without regard to each other.
       fix2        -          fix1 must be installed after fix2 is installed.
        -         fix1        fix2 must be installed after fix1 is installed.
       fix2       fix1        fix1 and fix2 must be installed together.
      !fix2        -          fix1 may not be installed after fix2 is installed.
        -        !fix1        fix2 may not be installed after fix1 is installed.
      !fix2      !fix1        fix1 and fix2 may not ever be installed together.
      !fix2       fix1        This is an erroneous specification.
       fix2      !fix1        This is an erroneous specification.

The installation index element provides ordering information for corequisite 
fixes that must be installed in a particular order.

Element Detail:

fix-prereq.efix-id         The id of the prerequisite fix.

fix-prereq.is-negative     A flag which indicates if the prerequisite
                           interim fix is required or prohibited.  If false,
                           you must install the interim fix before installing
                           the parent fix.  If true, you must not install
                           the interim fix before you install the parent fix.

fix-prereq.install-index   An optional index number which is used to
                           order corequisite fixes.

Element Type:     product-update

Elements:         product-id            string     required
                  product-name          string     required
                  build-version         string     required
                  build-date            date       required
                  build-level           string     required

Type Detail:

A product update specifies a replacement to a product file.

The product update information matches the information in product files.

Multiple product updates may be present, in which case each matching
product is updated.

Element Detail:

product-update.product-id     The id of the product that is updated.

product-update.product-name   The name of the product.

product-update.build-version  The build version of the product.

product-update.build-date     The build date of the product.

product-update.build-level    The build level of the product.

Element Type:     component-prereq

Elements:         component-name        string     required
                  spec-version          string     required
                  build-version         string     required
                  build-date            date       required

Element Type:     platform-prereq

Elements:         architecture          string     required
                  os-platform           string     optional
                  os-version            string     optional

Type Detail:

A platform prerequisite instance denotes a platform which must be present
for an update to be installed.  The element values are according to the
values supplied for the matching java properties.

Note that when multiple platform prerequisites are specified, these
prerequisites have an OR relationship: At least one of the platform
prerequisites must be satisfied.

Element Detail:

platform-prereq.architecture  The name of an architecture which must be
                              present.

platform-prereq.os-platform   The name of an operating system which
                              must be present.  This element is optional.
                              When absent, the architecture is checked,
                              but the os-platform and os-version are not.

platform-prereq.os-version    The version of a the operating system which
                              must be present.  This element is optional.
                              When absent, the architecture and os-platform
                              are checked, but os-version is not.  (When
                              os-platform is absent, os-version should not
                              be set.)

Element Type:     product-prereq

Elements:         product-id            string     required
                  build-version         string     optional
                  build-date            date       optional
                  build-level           string     optional

Type Detail:

A product prerequisite specifies that a particular product must be present 
for an update to be installed.

Note that when multiple product prerequisites are specified, these
prerequisites have an OR relationship: At least one of the product
prerequisites must be satisfied.

Note that all of the elements are required.  When multiple products having
the same id are supported by an update, multiple product prerequisites must
be specified.

Element Detail:

product-prereq.product-id     The id of the product which must be present.

product-prereq.build-version  The version of the product which must be present.

product-prereq.build-date     The build date of the product which must be present.

product-prereq.build-level    The level date of the product which must be present.

Element Type:     component-prereq

Elements:         component-name        string     required
                  spec-version          string     required
                  build-version         string     required
                  build-date            date       required

Type Detail:

A version prerequisite specifies that a particular component version must be
present for an update to be installed.

Note that when multiple version prerequisites are specified, these
prerequisites have an OR relationship: At least one of the version
prerequisites must be satisfied.

Element Detail:

version-prereq.component-name  The name of the component which must be present.

version-prereq.spec-version    The specification version of the component which
                               must be present.

version-prereq.build-version   The version of the component which must be present.

version-prereq.build-date      The build date of the component which must be
                               present.


Element Type:     included-efix

Elements:         efix-id               string     required

Type Detail:

An included-efix identifies an interim fix by ID and indicates that the fix
is included in the fix pack.

Element Detail:

included-efix.efix-id    The ID of the interim fix that the fix pack includes.

Element Type:     custom-property

Elements:         property-name         string     required
                  property-type         string     optional
                  property-value        string     optional

Type Detail:

A custom property encodes a key-value pair, with an optional type
element.  Custom properties are provided for future use.

Element Detail:

custom-property.property-name   The name of the custom property.

custom-property.property-type   An optional type of the custom property.
                                The semantics of this type are defined
                                by user of the property value.

custom-property.property-value  The value of the custom property.

File Type:        efix-applied

Persistence:      versionDir/id.efixApplied

Elements:         efix-id               string     required
                  component-applied     complex    min=0, max=unbounded

Type Detail:

An efix-applied collection specifies what components have been updated for
the interim fix as specified by the efix-id.

Element Detail:

efix-applied.efix-id            The id of the interim fix for which applieds 
                                are recorded.

efix-applied.component-applied  The list of recorded applications.

File Type:        ptf-applied

Persistence:      versionDir/id.ptfApplied

Elements:         ptf-id                string     required
                  component-applied     complex    min=0, max=unbounded

Type Detail:

A ptf-applied collection specified what components have been updated for
the fix pack as specified by the fix pack ID.

Element Detail:

ptf-applied.efix-id            The ID of the fix pack for which applieds are
                               recorded.

ptf-applied.component-applied  The list of recorded applications.

Element Type:     component-applied

Elements:         component-name        string     required
                  update-type           enum       required [enumUpdateType]
                  is-required           boolean    required
                  is-optional           boolean    required
                  is-external           boolean    required
                  root-property-file    anyURL     optional
                  root-property-name    string     optional
                  root-property-value   string     optional
                  is-custom             boolean    required
                  log-name              anyURL     required
                  backup-name           anyURL     required
                  time-stamp            date       required
                  initial-version       complex    optional
                  final-version         complex    optional

Type Detail:

An applied instance is present to indicate the application of an
update for a particular interim fix or fix pack to a particular component.
(The particular interim fix or fix pack is as specified by the applied's
parent.)  An applied provides sufficient information
to undo itself.

The elements of an applied are copies of values from update
events.

Element Detail:

component-applied.component-name   The name of the component which was updated.

component-applied.update-type      The type of the component update.

component-applied.is-required      A true value specifies that the parent
                                   update requires this component update.

component-applied.is-optional      A flag which, when true, specifies that the parent
                                   update does not require this component update,
                                   even if the component is installed.

component-applied.is-external          A flag which, when true, specifies that this
                                       component update was applied to a location
                                       different than the usual install_root.

component-applied.root-property-file   For an update against a component having an
                                       external root, this properties file provides
                                       the root value.

component-applied.root-property-name   For an update against a component having an
                                       external root, this named property provides
                                       the root value.

component-applied.root-property-value  For an update against a component having an
                                       external root, this is a record of the
                                       actual external root.

component-applied.is-custom        A flag which, when true, specifies that the
                                   application was a custom update.  When true, an
                                   executable program was applied.  When false, the
                                   contents of an update JAR were applied.

component-applied.log-name         The name of the log file that was generated by 
                                   this application.

component-applied.backup-name      The name of the backup file which was generated by
                                   this application.

component-applied.time-stamp       The time of this application (the ending time of
                                   the corresponding update event).

component-applied.initial-version  The version of the component before the
                                   application.  This version will be null if
                                   the application was an add.

component-applied.final-version    The version of the component after application.
                                   This will be null if the update was a removal.


Element Type:     initial-version

Elements:         component-name        string     required
                  spec-version          string     required
                  build-version         string     required
                  build-date            string     required

Type Detail:

A initial-version instance is used to describe a component level as
the initial version of a component.

Element Detail:

initial-version.component-name The name of the component.

initial-version.spec-version   The new specification version for the
                               component following the update.

initial-version.build-version  The new build version for the component.

initial-version.build-date     The new build date for the component.

Element Type:     final-version

Elements:         component-name        string     required
                  spec-version          string     required
                  build-version         string     required
                  build-date            string     required

Type Detail:

A final-version instance is used to supply a component level for a
component which has been added or replaced.

Element Detail:

final-version.component-name The name of the new component.

final-version.spec-version   The new specification version for the
                             component following the update.

final-version.build-version  The new build version for the component.

final-version.build-date     The new build date for the component.


Enum Type:        enumUpdateType

Values:           0 add
                  1 replace
                  2 remove
                  3 patch

Type Detail:

An update type instance specifies the type of an update.  An 'add' update adds
a component into an installation.  A 'replace' update replaces a particular
version of a component with a different version of that component.  A 'remove'
update removes a component.  A 'patch' update performs a limited update to a
component, in particular, without changing the version of the component.

When adding a component, that component may not already be present.
When replacing or removing a component, that component must be present.
When patching a component, that component must be present.

When replacing or removing a component, or when patching a component, usually,
at least one version prerequisite will be specified for the component update.

Value Detail:

enumUpdateType.add       Specifies that an update adds a component.

enumUpdateType.replace   Specifies that an update replaces a component.

enumUpdateType.remove    Specifies that an update removes a component.

enumUpdateType.patch     Specifies that an update modifies a component, but
                         does not change its version.


Type Family:      history

File Type:        event-history

Persistence:      historyDir/event.history

Elements:         update-event          complex    min=0, max=unbounded

Type Detail:

One event history is provided for a websphere product family installation.
This event history contains history of update events, corresponding with
the actual update events for that product family.

Element Detail:

event-history.update-event  The list of update events for the websphere
                            product family.  The top level events are fix
                            and fix pack events, each containing one or more
                            component events.

Element Type:     update-event

Elements:         event-type            enum       required [enumEventType]
                  parent-id             string     required
                  id                    string     required

                  update-type           enum       required [enumUpdateType]

                  is-required           boolean    required
                  is-optional           boolean    required

                  is-external           boolean    required
                  root-property-file    anyURL     optional
                  root-property-name    string     optional
                  root-property-value   string     optional

                  is-custom             boolean    required
                  primary-content       anyURI     required

                  event-action          enum       required [enumEventAction]
                  log-name              anyURI     required
                  backup-name           anyURI     required
                  start-time-stamp      dateTime   required
                  end-time-stamp        dateTime   optional

                  status                enum       optional [enumEventResult]
                  status-message        string     optional

                  initial-version       complex    optional
                  final-version         complex    optional
                  update-event          complex    optional

Type Detail:

An update event denotes a single update action, applying to either a
fix, a fix pack, or to a component, according to the set event type.

Interim fix (efix) and fix pack (ptf) type events each have a 
collection of component events.

Currently, component events have no child events.

Element Detail:

update-event.event-type        The type of this event, either an interim fix or
                               fix pack (ptf) type event, or a component type event.

update-event.parent-id         This element is present only for component
                               events. The ID of the parent interim fix or fix 
                               pack of this event.

update-event.id                The ID of the fix, fix pack, or component that
                               was updated, interpreted according to the type
                               of the event.

update-event.update-type       The type of update for component events.

update-event.is-required       A flag which, when true, specifies that this
                               component update is required.
                               
update-event.is-optional       A flag which, when true, specifies that this
                               component update is optional, even if the
                               component is installed.

update-event.is-external          A flag which, when true, specifies that this
                                  update used an external root.

update-event.root-property-file   For an update of an external component, this
                                  properties file contains the external root value.

update-event.root-property-name   For an update of an external component, the
                                  property having this name specifies the external
                                  root value.

update-event.root-property-value  For an update of an external component,
                                  the root value.

update-event.is-custom         A flag that, when true, specifies that the
                               application was a custom update.  When true,
                               an executable program was applied.  When false,
                               the contents of an update JAR file were applied.

update-event.primary-content   The URL of the primary content for the update.

update-event.event-action      The type of action for this event.

update-event.log-name          The name of the log file that was generated
                               for this event.

update-event.backup-name       The name of the backup file that was generated
                               for this event.

update-event.start-time-stamp  The XML timestamp of the starting time of the
                               event.  This timestamp follows the XML timestamp
                               format, meaning that time zone information is
                               included.

update-event.end-time-stamp    The XML timestamp of the ending time of the
                               event.  This timestamp follows the XML timestamp
                               format, meaning that time zone information is
                               included.  When absent, the update operation
                               corresponding to the parent event failed with
                               a non-recoverable exception.

update-event.status            The result of the update.

update-event.status-message    Message text provided in addition to the basic
                               status code.  Exception text is provided through
                               the status-message when an update fails.

update-event.initial-version   This element is not used unless the update is
                               a component type update.  The initial version of
                               the component which was updated.    This element
                               is absent when the update is an add type update.

update-event.final-version     This element is not used unless the update is a
                               component type update.  The final version of the
                               component which was updated.  This element is absent
                               when the update is a remove type update.

update-event.update-event      A collection of child events.  This collection is
                               used for interim fix and fix pack type events.  
                               This collection is empty for component type events.

Element Type:     initial-version

Elements:         spec-version          string     required
                  build-version         string     required
                  build-date            string     required

Type Detail:

A initial-version instance is used to describe a component level as
the initial version of a component.

Element Detail:

initial-version.spec-version   The new specification version for the
                               component following the update.

initial-version.build-version  The new build version for the component.

initial-version.build-date     The new build date for the component.

Element Type:     final-version

Elements:         spec-version          string     required
                  build-version         string     required
                  build-date            string     required

Type Detail:

A final-version instance is used to supply a component level for a
component which has been added or replaced.

Element Detail:

final-version.spec-version   The new specification version for the
                             component following the update.

final-version.build-version  The new build version for the component.

final-version.build-date     The new build date for the component.

Enum Type         enumEventType

Values:           0 Interim fix (efix)
                  1 Fix pack (ptf)
                  2 Component

Type Detail:

An event type instance specifies the type of an update event, which is either
an interim fix (efix) event, a fix pack (ptf) event or a component event. The 
interpretation of particular event elements depends on the set event type.

Value Detail:

enumEventType.efix       Specifies that an event is for an interim fix update.

enumEventType.ptf        Specifies that an event is for a fix pack update.

enumEventType.component  Specifies that an event is for a component update.

Enum Type:        enumEventAction

Values:           0 Install
                  1 Uninstall
                  2 Selective install
                  3 Selective uninstall

Type Detail:

An event action instance specified the operation performed by an update, which
can be an install or uninstall operation, and which may be a selective operation.
Component operations are always either install or uninstall type operations, only
interim fix and fix pack operations may be selective operations.

A selective operation is an installation which is applied to a preset list of
components.  In particular, potential component updates may be skipped, and
component updates which were already applied may be reapplied.

A selective uninstall operation is used to back out an update which was cancelled
by the user.

Value Detail:

enumEventAction.install              Specifies that an event is an install
                                     operation.

enumEventAction.uninstall            Specifies that an event is an uninstall
                                     operation.

enumEventAction.selective-install    Specifies that an event is an install
                                     operation with a preset list of components
                                     that are updated.

enumEventAction.selective-uninstall  Specifies that an event is an uninstall
                                     operation with a preset list of components
                                     that are updated.

Enum Type:        enumUpdateType

Values:           0 Add
                  1 Replace
                  2 Remove
                  3 Patch

Type Detail:

An update type instance specifies the type of a component update.  
An 'add' update adds a component into an installation.  
A 'replace' update replaces a particular version of a component with 
a different version of that component.
A 'remove' update removes a component.  
A 'patch' update performs a limited update to a component, 
in particular, without changing the version of the component.

To add a new component, the component must not exist. 
To replace or remove a component, the component must exist. 
To patch a component, the component must exist.

When replacing or removing a component, or when patching a component, 
usually, at least one version prerequisite is specified for the 
component update.

Value Detail:

enumUpdateType.add       Specifies that an update adds a component.

enumUpdateType.replace   Specifies that an update replaces a component.

enumUpdateType.remove    Specifies that an update removes a component.

enumUpdateType.patch     Specifies that an update modifies a component, but
                         does not change its version.

Enum Type:        enumEventResult

Values:           0 Succeeded
                  1 Failed
                  2 Cancelled

Type Detail:

An event result instance denotes a particular result for an update event. 
The result indicates success, failure, or cancellation.

Value Detail:

enumEventResult.succeeded  Specifies that the operation was successful.

enumEventResult.failed     Specifies that the operation failed.

enumEventResult.cancelled  Specifies that the operation was cancelled.

versionInfo command

The versionInfo command generates reports from data it extracts from XML files in the properties/version folder.

Product version and history information

The /properties/version directory in the installation root contains important data about the product and its installed components, such as the build version and build date. This information is included in product.product and component.component files. The /properties/version/history directory in the installation root contains a collection of records for installed interim fixes and fix packs. This information is included in interim fixID.efixApplied, interim fixID.efixDriver, fix packID.ptfApplied, and fix packID.ptfDriver files. A driver file has useful information about the entire contents of an interim fix or fix pack. The applied file has relevant information about the interim fixes or fix packs that are currently applied. Event.history files are also present. They contain a detailed log about updates you have applied, either successfully or unsuccessfully. Time-stamped, detailed logs record each update process in the /properties/version/log directory of the installation root.

You can view product information by examining files in the properties/version directory, including the properties/version/history directory. WebSphere Application Server also provides the ability to generate two types of reports about the data in the files, Version reports and History reports.

Restriction: There is one restriction. Do not use the versionInfo.sh or versionInfo.bat script while installing or uninstalling the product, or while installing or uninstalling an interim fix or fix pack.

Product version reports

The following report generation scripts extract data from XML data files in the properties/version folder:

Location of the command file

The command file is a script. On Linux and UNIX platforms, the command file is named versionInfo.sh in the install_root/bin directory. On Windows platforms, the command file is named versionInfo.bat in the install_root\bin directory.

Syntax for the versionInfo command on a Linux or UNIX-based platform

The command syntax is:

versionInfo.sh [ -format text | html]
               [ -file output file]
               [ -long ]
               [ -efixes ]
               [ -efixDetail ]
               [ -ptfs ]
               [ -ptfDetail ]
               [ -components ]
               [ -componentDetail ]


versionInfo.sh [ -help | -? | /help | /? | -usage ]

Issue the command from the install_root/bin directory.

Syntax for the versionInfo command on a Windows platform

The command syntax is:

versionInfo [ -format text | html]
            [ -file output file]
            [ -long ]
            [ -efixes ]
            [ -efixDetail ]
            [ -ptfs ]
            [ -ptfDetail ]
            [ -components ]
            [ -componentDetail ]


versionInfo [ -help | -? | /help | /? | -usage ]

Issue the command from the install_root\bin directory.

Parameters

-? or /? (Windows only)
Displays command syntax.
-components
Adds a list of installed components to the report.
-componentDetail
Adds details about installed components to the report.
-efixes
Adds a list of applied interim fixes to the report.
-efixDetail
Adds details about applied interim fixes to the report.
-file fileName
Specifies the output file name. The report goes to standard output (stdout) by default.
-format text | html
Selects the format of the report. The default is "text".
-help or /help (Windows only)
Displays command syntax.
-long
Creates the long version of the report.
-ptfDetail
Adds details about applied fix packs to the report.
-ptfs
Adds a list of applied fix packs to the report.
-usage
Displays command syntax.

Logging

As the tool runs, it creates reports instead of log entries. Reports appear on the console unless directed to a file with the -file filename parameter. There is no default file name. You must specify a file name to generate a file.

When issued on a Windows platform, from the bin directory of the Network Deployment product that has no interim fixes or fix packs applied, the versionInfo.bat script displays the following information:

D:\Program Files\WebSphere\DeploymentManager\bin>versionInfo
WVER0010I: Copyright (c) IBM Corporation 2002; All rights reserved.
WVER0011I: WebSphere Application Server Release 5.0
WVER0012I: VersionInfo reporter version 1.14, dated 5/9/03

----------------------------------------------------------

IBM WebSphere Application Server Product Installation Status Report
----------------------------------------------------------



Report at date and time 2003-10-05T11:01:45-04:00

Installation
----------------------------------------------------------

Product Directory   D:\Program Files\WebSphere\DeploymentManager
Version Directory   ${product.dir}\properties\version
DTD Directory       ${version.dir}\dtd
Log Directory       D:\Program Files\WebSphere\DeploymentManager\logs\update
Backup Directory    ${version.dir}\backup
TMP Directory       D:\DOCUME~1\ADMINI~1\LOCALS~1\Temp

Installation Platform
----------------------------------------------------------

Name           IBM WebSphere Application Server
Version        5.1

Technology List
----------------------------------------------------------

ND             installed

Installed Product
----------------------------------------------------------

Name           IBM WebSphere Application Server Network Deployment
Version        5.1.0
ID             ND
Build Level    b0334.18
Build Date     8/30/03

---------------------------------------------------------

End Installation Status Report
---------------------------------------------------------

genVersionReport command

The genVersionReport command generates the versionReport.html report file in the bin directory on Linux and UNIX-based platforms, or on Windows platforms. The report includes the list of components, fixes, and fix packs.

Product version and history information

The /properties/version directory in the installation root contains important data about the product and its installed components, such as the build version and build date. This information is included in [product].product and [component].component files. The /properties/version/history directory in the installation root contains a collection of records for installed interim fixes and fix packs. This information is included in [interim fixID].efixApplied, [interim fixID].efixDriver, [fix packID].ptfApplied, and [fix packID].ptfDriver files. A driver file has useful information about the entire contents of an interim fix or fix pack. The applied file has relevant information about the interim fixes or fix packs that are currently applied. Event.history files are also present. They contain a detailed log about updates you have applied, either successfully or unsuccessfully. Time-stamped, detailed logs record each update process in the /properties/version/log directory of the installation root.

You can view product information by examining files in the properties/version directory, including the properties/version/history directory. WebSphere Application Server also provides the ability to generate two types of reports about the data in the files, Version reports and History reports.

Product version reports

The following report generation scripts extract data from XML data files in the properties/version folder:

Location of the command file

The command file is a script. On Linux and UNIX platforms, the command file is named genVersionReport.sh in the install_root/bin directory. On Windows platforms, the command file is named genVersionReport.bat in the install_root\bin directory.

Syntax for the versionInfo command on a Linux or UNIX-based platform

The command syntax is:

genVersionReport.sh 

Issue the command from the install_root/bin directory.

Syntax for the versionInfo command on a Windows platform

The command syntax is:

genVersionReport.bat

Issue the command from the install_root\bin directory.

Logging

As the tool runs, it creates the versionReport.html report file instead of log entries.

Creating the report

This example shows how to issue the command on a Windows platform, from the bin directory of the Network Deployment product:

D:\Program Files\WebSphere\DeploymentManager\bin>genVersionReport
WVER0010I: Copyright (c) IBM Corporation 2002; All rights reserved.
WVER0011I: WebSphere Application Server Release 5.0
WVER0012I: VersionInfo reporter version 1.14, dated 5/9/03

When the Network Deployment product has no interim fixes or fix packs applied, the genVersionReport.bat script creates the following information in the versionReport.html report file, which is edited to show only the first few components:

IBM WebSphere Application Server Product Installation Status Report

----------------------------------------

 Report at date and time 2003-10-05T11:58:40-04:00

 Installation
 Product Directory D:\Program Files\WebSphere\DeploymentManager
 Version Directory ${product.dir}\properties\version
 DTD Directory ${version.dir}\dtd
 Log Directory D:\Program Files\WebSphere\DeploymentManager\logs\update
 Backup Directory ${version.dir}\backup
 TMP Directory D:\DOCUME~1\ADMINI~1\LOCALS~1\Temp


 Installation Platform
 Name IBM WebSphere Application Server
 Version 5.1


 Technology List
 ND installed


 Installed Product
 Name IBM WebSphere Application Server for Network Deployment
 Version 5.1.0
 ID ND
 Build Level b0334.18
 Build Date 8/30/03


 Installed Component
 Component Name activity
 Spec Version 5.0
 Build Version b0334.18
 Build Date 8/30/03


 Installed Component
 Component Name activity.impl
 Spec Version 5.0
 Build Version b0334.18
 Build Date 8/30/03


 Installed Component
 Component Name activity.session
 Spec Version 5.0
 Build Version b0334.18
 Build Date 8/30/03


----------------------------------------

End Installation Status Report

Notices

References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program, or service. Evaluation and verification of operation in conjunction with other products, except those expressly designated by IBM, is the user's responsibility.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

    IBM Director of Licensing
    IBM Corporation
    500 Columbus Avenue
    Thornwood, New York  10594 USA

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

Trademarks and service marks

The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both:

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

LINUX is a trademark of Linus Torvalds in the U.S., other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

Other company, product and service names may be trademarks or service marks of others.