About this readme_updateinstaller document
Product version and history information
This readme_updateinstaller document describes procedures for using the update installer application to install an interim fix or fix pack on the base WebSphere Application Server product, the Network Deployment product, or the Enterprise product. This readme also describes how to remove an interim fix or fix pack from these WebSphere Application Server products.
You can also use the update installer to install interim fixes and fix packs on the WebSphere Application Server - Express product and on the WebSphere Application Server client. This readme 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 or fix pack.
All of the information in this document is available in the online Information Center.
Install interim fixes on these WebSphere Application Server products using the following procedures:
Use the generic procedure described in the updateSilent or updateWizard command descriptions to install interim fixes on the WebSphere Application Server-Express product or on the WebSphere Application Server client.
Download interim fixes to a read/write directory as described in the readme for the interim fix. Installing from a read only drive is not supported at this time.
On AIX, the updateWizard interface to the update installer fails to detect an installation of IBM WebSphere Application Server, Version 5.1 or IBM WebSphere Application Server Network Deployment, Version 5.1.
On HP-UX, the updateWizard interface to the update installer fails to detect an installation of IBM WebSphere Application Server, Version 5.1 or IBM WebSphere Application Server Network Deployment, Version 5.1. When this occurs, the updateWizard interface throws a NULL Pointer exception in the AIX console but not in the HP-UX console.
Manually point to the install location of the installed Version 5.1 product and ignore any null pointer exception.
There are two ways to point to the product. You can use the updateWizard command and manually enter the location after the interface throws the exception. Or you can use the updateSilent command and enter the installDir parameter as part of the command.
The update installer application installs and uninstalls interim fixes on WebSphere Application Server products. There are two interfaces to the installer application, a wizard with a graphical interface, and a command-line, silent interface.
This topic describes the proper procedure for installing an interim fix on a stand-alone IBM WebSphere Application Server, V5.1 environment, using the update installer application.
To apply an interim fix, first set up and configure the environment by downloading the interim fix and the update installer, creating update repositories, and setting the JAVA_HOME environment variable. Then use the update installer to install the interim fix, using either the wizard interface, which is the updateWizard command, or the silent, command-line interface, which is the updateSilent command.
The update installer application can also uninstall interim fixes.
If the base WebSphere Application Server node is within a cell, go to Installing interim fixes on the Network Deployment product. This topic describes applying an interim fix to a stand-alone base node.
Use the versionInfo command in the install_root/bin directory to display the exact fix and version level of the product. Do not use the versionInfo command while installing or uninstalling an interim fix.
You can also use the silent update installer application to view interim fix information.
Before installing or uninstalling interim fixes, stop all Java processes that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, such as the IBM Developer Kit for AIX, Java Technology Edition. Stop all application servers, and all servers, such as the IBMHttpServer process, that belong to serviceable features. Features with servers include the IBM HTTP Server and the embedded messaging feature. Stop all Java processes, if necessary. If you do install or uninstall an interim fix while a WebSphere Application Server-related Java process is running, IBM does not guarantee that the product can continue to run successfully, or without error.
This procedure describes a scenario for updating a stand-alone base node by installing an interim fix. The Uninstalling interim fixes topic describes how to remove an interim fix from a stand-alone base node.
Space requirements vary depending on what you are installing. The size of each download is available on the Support site. Verify that the free space is available before beginning the installation. After unpacking the ZIP file, you can delete the ZIP file to free space if necessary.
Space is required for the read/write directory, such as /usr/temp/update, for downloading and unpacking the interim fix. Space is also required for backup files in the /properties/version/backup directory of the product installation root.
Steps for this task
Stop all Java processes related to WebSphere Application Server. On a Windows platform, use the task manager to stop Java processes. On a UNIX-based platform, use the kill command to stop Java processes.
Download the current version of the file even though you might have an update installer from a previous interim fix installation. The Support page links to the current installer.
Download an interim fix from the Support page to the /update/fixes directory.
On Windows platforms, the pkunzip utility might not decompress the download image correctly. Use another utility (such as WinZip) to unzip the image.
If the update installer can set the Java environment, this step is not necessary. Otherwise, this is a required step.
If the update installer cannot set the JAVA_HOME environment variable, you receive a message that the update installer cannot set JAVA_HOME. In such a case, set the environment variable yourself, or issue the appropriate command script from the /bin directory of the installation root:
For example, to install the xxyyzz1 interim fix, use this updateSilent command:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\temp\update\fixpacks"
-install
-fixes xxyyzz1
The command is shown here on more than one line, for clarity.
./startNode.sh
./startServer.sh server1
If the node is part of a cell:
./startServer.sh jmsserver
There are several ways to verify the successful application of an interim fix:
Run the installation verification tool on the node as described in the InfoCenter to verify that the node is operational.
This topic describes the proper procedure for installing an interim fix in an IBM WebSphere Application Server Network Deployment, V5 environment, using the update installer application.
To apply an interim fix, first set up and configure the environment by downloading the interim fix and the update installer, creating update repositories, and setting the JAVA_HOME environment variable. Then use the update installer to install the interim fix, using either the wizard interface, which is the updateWizard command, or the silent, command-line interface, which is the updateSilent command.
The update installer application can also uninstall fixes.
One requirement governs applying an interim fix to a cell, to verify the continued, smooth interaction of the various WebSphere Application Server nodes:
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.0.1 base WebSphere Application Server node to a V5.1.0.0 deployment manager cell.
There is no limitation on the interim fix 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 to the number of different V5 interim fix levels that can coexist or interoperate within a cell, so long as each base node fix level is the same as, or lower than, that of the deployment manager.
Verify that the interim fix level of each base WebSphere Application Server node within the cell is lower than, or identical to, the level of the deployment manager. No base node within the cell is allowed to be at a higher level than the deployment manager node. Uninstall an interim fix from every base node if you uninstall the fix from the deployment manager node.
Use the versionInfo command in the install_root/bin directory to display the exact interim fix and version level of the product. Do not use the versionInfo command while installing or uninstalling an interim fix.
You can also use the silent update installer application to view interim fix information.
Before installing or uninstalling interim fixes, stop all Java processes that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, such as the IBM Developer Kit for AIX, Java Technology Edition. Stop all application servers, the nodeagent, the deployment manager server, and all servers, such as the jmsserver, that belong to serviceable features. Features with servers include the IBM HTTP Server and the embedded messaging feature. Stop all Java processes, if necessary. If you do install or uninstall an interim fix while a WebSphere Application Server-related Java process is running, IBM does not guarantee that the product can continue to run successfully, or without error.
This procedure describes a scenario for updating an entire cell to the same fix level. According to the requirements, you can install an interim fix to the deployment manager node only, without applying it to other nodes in the cell. Install the interim fix to zero, one, or more of the base nodes after you apply it to the deployment manager node.
After upgrading a deployment manager node from V5 to V5.0.1 or V5.0.2, restart all node agents in the cell to verify correct operation. This includes node agents on base nodes that you have not updated to V5.0.1.
Uninstalling fixes describes how to remove an interim fix from an entire cell, or from any part of the cell. According to the guidelines, uninstall the fix from each base node in a cell before you uninstall the fix from the deployment manager node.
Installing a fix pack uninstalls all interim fixes. Fixes at a later level than the fix pack are not included in the fix pack. Reinstall such fixes to bring your system back to the previous fix level.
Space requirements vary depending on what you are installing. The size of each download is available on the Support site. Verify that the free space is available before beginning the installation. After unpacking the ZIP file, you can delete the ZIP file to free space if necessary.
Space is required for the /update directory of the product installation root. The space required is about the same as the size of the fix.
Space is also required for backup files in the /properties/version/backup directory of the product installation root.
Interim fixes require much less space to install than fix packs do.
Steps for this task
The stopNode command is in the install_root/bin directory of each base node.
Stop all WebSphere Application Server-related Java processes such as the jmsserver process.
The dmgr Java process is the deployment manager process. The stopManager command is in the install_root/bin directory of each base node.
Download the current version of the file, even though you might have an update installer from a previous interim fix installation. The Support page links to the current installer.
Download the interim fix from the Support page to the install_root/update/fixes repository directory.
On Windows platforms, the pkunzip utility might not decompress the download image correctly. Use another utility (such as WinZip) to unzip the image.
If the update installer cannot set the JAVA_HOME environment variable, you see a message that the update installer cannot set JAVA_HOME. In this case, set the environment variable yourself, or issue the appropriate command script from the bin directory of the installation root:
Use the appropriate command to apply the interim fix on the deployment manager node:
The dmgr Java process is the deployment manager process. The startManager command is in the install_root/bin directory of the deployment manager node.
There are several ways to verify the successful application of an interim fix:
Run the installation verification tool on the node as described in the InfoCenter to verify that the node is operational.
Restart the node agent on each base node, to let the node agent continue to communicate with the updated deployment manager node. Restart all node agents if that is more convenient. Do not restart node agents on base nodes that you intend to update with the interim fix. The interim fix installation requires you to stop and restart the node agent.
The startNode command is in the install_root/bin directory of each base node.
Verify consistent configuration data across a cell. 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. 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.
At this point the cell is fully functional. All operations are available and function normally.
Uninstall fixes from these WebSphere Application Server products using the following procedures:
Use the generic procedure described in the updateSilent or updateWizard commands to remove fixes from the WebSphere Application Server-Express product or from the WebSphere Application Server client.
This topic describes the proper procedure for uninstalling an interim fix in an IBM WebSphere Application Server, V5 environment using the update installer application.
Removing an interim fix 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. If you use a non-standard installation root directory for your WebSphere Application Server product, 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 you can use the update installer to uninstall the interim fix, using either its wizard interface, the updateWizard command, or its silent, command-line interface, the updateSilent command.
The update installer application can also install fixes.
If the base WebSphere Application Server node is within a cell, go to Removing fixes from the Network Deployment product. This topic describes removing an interim fix from a stand-alone base node.
Use the versionInfo command in the install_root/bin directory to display the exact interim fix and version level of the product. Do not use the versionInfo command while installing or uninstalling an interim fix.
You can also use the silent update installer application to view interim fix information.
Before installing or uninstalling interim fixes, stop all Java processes that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, such as the IBM Developer Kit for AIX, Java Technology Edition. Stop all application servers, and all servers, such as the IBMHttpServer process, that belong to serviceable features. Features with servers include the IBM HTTP Server and the embedded messaging feature. Stop all Java processes, if necessary. If you do install or uninstall an interim fix while a WebSphere Application Server-related Java process is running, IBM does not guarantee that the product can continue to run successfully, or without error.
This procedure describes a scenario for updating a stand-alone base node by removing an interim fix. The Installing fixes topic describes how to install an interim fix on a stand-alone base node.
Steps for this task
Set up the Java environment for the update installer.
The location of the update, fixes repository, and fixpacks repository directories is arbitrary. Create the directories anywhere. However, the install_root/update, install_root/update/fixes, and install_root/update/fixpacks locations are recommended.
If you use a non-standard installation root, it is possible that the updateWizard (or updateSilent) command 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 yourself, from the bin directory of the installation root:
There are several ways to verify the successful application of an interim fix:
Run the installation verification tool on the node as described in the InfoCenter to verify that the node is operational.
This topic describes the proper procedure for uninstalling an interim fix in an IBM WebSphere Application Server Network Deployment, V5 environment using the update installer application.
Removing an interim fix 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. If you use a non-standard installation root directory for your WebSphere Application Server product, 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 up the Java environment, set the JAVA_HOME variable yourself. Then use the update installer to uninstall the interim fix, using either its wizard interface, the updateWizard command, or its silent, command-line interface, the updateSilent command.
The update installer application can also install fixes.
One requirement governs removing an interim fix from a cell, to verify the continued, smooth interaction of the various WebSphere Application Server nodes: The Network Deployment product must be at the highest interim fix level within the cell.
For example, you cannot use the addNode command of a base WebSphere Application Server node at V5.0.2, to add it to a cell that is owned by a V5.0.1 deployment manager.
There is no limitation on the fix or fix level of a base WebSphere 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 to the number of different V5 fix or fix levels that can coexist or interoperate within a cell, so long as each base node fix level is the same as, or lower than, that of the deployment manager.
Verify that the interim fix level of each base WebSphere Application Server node within the cell, is at a lower or identical level as the deployment manager. No base node within the cell is allowed to be at a higher level than the deployment manager node. Uninstall an interim fix from every base node, if you uninstall the interim fix from the deployment manager node.
Use the versionInfo command in the install_root/bin directory to display the exact fix and version level of the product. Do not use the versionInfo command while installing or uninstalling an interim fix.
You can also use the silent update installer application to view interim fix information.
Before installing or uninstalling fixes, stop all Java processes that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, such as the IBM Developer Kit for AIX, Java Technology Edition. Stop all application servers, the nodeagent, the deployment manager server, and all servers, such as the jmsserver, that belong to serviceable features. Features with servers include the IBM HTTP Server and the embedded messaging feature. Stop all Java processes, if necessary. If you do install or uninstall an interim fix while a WebSphere Application Server-related Java process is running, IBM does not guarantee that the product can continue to run successfully, or without error.
This procedure describes a scenario for removing an interim fix from an entire Network Deployment cell, or from any part of the cell. According to the guidelines, uninstall the interim fix from each base node in a cell before you uninstall the interim fix from the deployment manager node.
Installing interim fixes describes how to apply an interim fix to an entire cell, or to selected parts of the cell.
If you plan to uninstall the Network Deployment product, uninstall all interim fixes before uninstalling the product.
Always uninstall the highest level interim fix before uninstalling other interim fixes or fix packs.
Steps for this task
Determine the base nodes from which you intend to remove the interim fix. For each node perform this procedure, Removing interim fixes from the base product.
If you remove the interim fix from every base node in the cell, you can also remove the interim fix from the Network Deployment node. The fix level of the Network Deployment node must be equal to, or higher than the fix level of any base node in the cell.
Use the following procedure to perform this task:
Set up the Java environment for the update installer.
The location of the update, fixes repository, and fixpacks repository directories is arbitrary. Create the directories anywhere. However, the install_root/update, install_root/update/fixes, and install_root/update/fixpacks locations are recommended.
If you use a non-standard installation root, it is possible that the updateWizard (or updateSilent) command 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 yourself, from the bin directory of the installation root:
There are several ways to verify the successful removal of an interim fix:
Run the installation verification tool on the node as described in the InfoCenter to verify that the node is operational.
Verify consistent configuration data across a cell. 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. 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.
At this point the cell is fully functional. All operations are available and function normally.
The updateSilent command is the silent, command-line interface to the IBM WebSphere Application Server update installer application. You can also use a wizard interface to the update installer application, the updateWizard command. The update installer installs and uninstalls fixes and fix packs for WebSphere Application Server products. This topic describes using the silent interface to the update installer command, and its command-line parameters to install and uninstall interim fixes.
Stop all Java processes on the machine that use the IBM SDK that WebSphere Application Server provides Before installing or uninstalling interim fixes on a machine, 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, such as the IBM Developer Kit for AIX, Java Technology Edition. Stop all application server processes, the nodeagent process, the deployment manager process, and all server processes, such as the jmsserver process, that belong to serviceable features. Features with server processes include the IBM HTTP Server and the embedded messaging feature. Stop all Java processes, if necessary. If you do install or uninstall an interim fix 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 at one time The update installer cannot be launched concurrently with itself. Performing more than one update at the same time can lead to a failed or faulty installation.
Verify that the free space is available before beginning the installation. After unpacking the ZIP file, you can delete the ZIP file to free space if necessary.
Space is also required for backup files in the install_root/properties/version/backup directory. Fixes require much less space than fix packs.
The update installer checks for required space before it installs the fix pack.
The update installer checks for required disk space in the /tmp directory and in the backup directory. If there is not enough space in the /tmp directory or there is not enough space in the backup directory, the update installer issues a warning message.
If you use a non-standard installation root, it is possible that the updateWizard command cannot set the JAVA_HOME environment variable. If you receive a message that the wizard is unable to set JAVA_HOME, set the environment variable yourself, or issue the appropriate command script yourself, from the /bin directory of the installation root:
Create an update directory if it does not exist, download the update installer application ZIP file from the Support site to the update directory, and unzip the file.
On Windows platforms, the pkunzip utility might not decompress the download image correctly. Use another utility (such as WinZip) to unzip the image.
The update installer records processing results in log files in theinstall_root/logs/update directory. Backup files created during the installation of interim fixes are in the install_root/properties/version/backup directory. The files are required to uninstall an interim fix.
The silent update application actually provides two functions. Depending upon the parameters you choose, the command:
The following examples describe the syntax of various uses of the update installer. In each example, optional parameters are enclosed by brackets ([]). Values that you supply appear in italicized font. Choices are denoted by the pipe symbol (|).
updateSilent -help | -? | /help | -usage
updateSilent /help | -? | -usage (Windows platforms only)
updateSilent myProps.properties
updateSilent -installDir "fully qualified product install_root"
-fix
-fixDir "fully qualified fix repository root,
usually install_root/update/fixes"
-install | -uninstall | uninstallAll
-fixes space-delimited list of fixes
-fixJars space-delimited list of fix JAR files
[-fixDetails]
[-prereqOverride]
updateSilent -fix
-installDir "fully qualified product install_root"
updateSilent -fix
-installDir "fully qualified product install_root"
-fixDir "fully qualified fix repository root,
usually install_root/update/fixes"
Use the following parameters for the updateSilent command:
The current Application Server strategy for fix pack JAR files is to use one JAR file per fix pack. The fix pack ID is the name of the JAR file before the .jar extension. For example:
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:
For example, a sample.properties file for installing two
interim 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
If you installed the IBM HTTP Server product as a feature, use the update installer to update it with service in an interim fix. Otherwise, download an updated IBM HTTP Server product 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.
Update your configuration if you reinstall. The process is described in the Manually configuring supported Web servers (tins_manualWebserver) topic in the InfoCenter for the base Application Server.
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 to update the embedded messaging feature with service in an interim fix. Skip the installation of service to the embedded messaging feature if you install corrective service to the stand-alone IBM WebSphere MQ product.
You must uninstall all interim fixes and fix packs before uninstalling the base WebSphere Application Server product or the Network Deployment product. However, you can use the manual uninstalling procedure described in the information center to uninstall everything manually without removing any interim fixes or fix packs.
The following examples assume that:
Examples in this section include:
Most of the examples are split into more than one line, for clarity.
To get help for the updateSilent command:
C:\Program Files\WebSphere\AppServer\update> updateSilent -help
To use the myProps.properties file to supply parameter values for the updateSilent command:
C:\Program Files\WebSphere\AppServer\update> updateSilent myProps.properties
To install a collection of interim fixes:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-install
-fixes Fix1 Fix2
To install a collection of interim fixes, and display interim fix details:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-install
-fixes Fix1 Fix2
-fixDetails
To install a collection of fixes, and override prerequisite checking:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-install
-fixes Fix1 Fix2
-prereqOverride
To install interim fixes from a Java archive (JAR) file:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-install
-fixJar Fix1
To install interim fixes from a Java archive (JAR) file, and display interim fix details:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-install
-fixJar Fix1
-fixDetails
To install interim fixes from a Java archive (JAR) file, and override prerequisite checking:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-install
-fixJar Fix1
-fixDetails
To uninstall a collection of interim fixes:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-uninstall
-fixes Fix1 Fix2
To uninstall a collection of interim fixes, and display interim fix details:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-uninstall
-fixes Fix1 Fix2
-fixDetails
To uninstall a collection of interim fixes, and override prerequisite checking:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-uninstall
-fixes Fix1 Fix2
-prereqOverride
To uninstall interim fixes in a Java archive (JAR) file:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-uninstall
-fixJar Fix1
To uninstall interim fixes in a Java archive (JAR) file, and display interim fix details:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-uninstall
-fixJar Fix1
-fixDetails
To uninstall interim fixes in a Java archive (JAR) file, and override prerequisite checking:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
-uninstall
-fixJar Fix1
-fixDetails
To view a list of installed interim fixes:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
To view a list of interim fixes available in the repository:
C:\Program Files\WebSphere\AppServer\update> updateSilent -fix
-installDir "C:\Program Files\WebSphere\AppServer"
-fixDir "C:\Program Files\WebSphere\AppServer\update\fixes"
The updateWizard command is the wizard interface to the IBM WebSphere Application Server update installer application. You can also use a silent, command-line interface to the update installer application, the updateSilent command. The update installer installs and uninstalls interim fixes and fix packs for WebSphere Application Server products.
This topic describes using the wizard interface to the update installer to install and uninstall interim fixes. The information describes all panels and fields you might use to install or uninstall an interim fix.
Before installing or uninstalling interim fixes, stop all Java processes that use the IBM SDK that WebSphere Application Server provides to support the Java 2 SDK on your operating system platform, such as the IBM Developer Kit for AIX, Java Technology Edition. Stop all application server processes, the nodeagent process, the deployment manager process, and all server processes, such as the jmsserver process, that belong to serviceable features. Features with server processes include the IBM HTTP Server and the embedded messaging feature.
Stop all Java processes, if necessary. If you do install or uninstall an interim fix while a WebSphere Application Server-related Java process is running, IBM does not guarantee that the product can continue to run successfully, or without error.
On a Windows platform, remove the WebSphere MQ tray icon if it 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.
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.
For example:
install_root/update/updateWizard.sh install_root\update\updateWizard.bat (Windows only)
Apply zero, one, or more of these optional parameters in any order, by issuing the updateWizard command from the command line.
The default behavior of the update installer application prevents further action if prerequisites are missing.
To install and uninstall interim fixes, the updateWizard 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 enables both interim fix and fix pack installation and uninstallation. 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 SDK from the JAVA_HOME directory to the directory where you are running the updateWizard (usually install_root/update). If the IBM SDK is already in the directory (for example, if you used the updateWizard command before), it is not necessary for the updateWizard to make a new copy.
The copy of the IBM SDK remains in the directory until you remove it. The IBM SDK requires approximately 43 MB of free space.
If you install on a client platform, where there is a Java runtime environment instead of the IBM SDK, the updateWizard copies the JRE to the install_root/update directory. The JRE requires about 18 MB of free space.
This command displays information about command syntax.
updateWizard -usage
The following command bypasses making a local copy of the IBM Developer Kit. Installing and uninstalling fixes does not require the local copy.
updateWizard -fixOnly
Disabling prerequisite checking is recommended only as directed by IBM Support personnel. Disabling prerequisite checking can leave the installation in a non-valid state, unless done with caution and guidance.
To disable prerequisite checking when installing interim fixes:
updateWizard -fixOnly -dpInstall
To disable prerequisite checking when uninstalling interim fixes:
updateWizard -fixOnly -dpInstall
To disable prerequisite locking when installing and when uninstalling interim fixes:
updateWizard -fixOnly -dpInstall -dpUninstall
Panels in the wizard let you select installable interim fixes, view installed interim fixes, and view prerequisite fixes:
Use this panel to view a welcome message that contains a brief summary of the update wizard interface, or to link to the Support Web site. (This link is not available on some UNIX-based platforms.) You can also view relevant legal notices.
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 Installation directory field. To make corrections or enter another product location, click Specify product location.
On some platforms, there is a limitation in the InstallShield for MultiPlatforms (ISMP) program that the update installer program uses. The ISMP program does not recognize previous installations of WebSphere Application Server on some operating platforms. To work around the problem, click Specify product location and type the fully qualified installation root directory for the existing product in the Installation directory field.
Use this panel to install or uninstall interim fixes. If you started the wizard in -fixOnly mode, fix pack options are disabled.
Use this panel to provide the interim fix repository location in a directory input field. Specify the directory location of the downloaded fix JAR files. The default location for the repository is the install_root/update/fixes directory.
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 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 is a collection of updates to one or more product components. Depending on installed product components and on update installer selections you make, the update installer applies either a full or partial set of interim fix updates to product components.
Installed status implies that the interim fix 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 has at least one more update to 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:
The status changes dynamically from installed to partially installed.
Use this panel to select one or more installed interim fixes for uninstalling. Available interim fixes do not appear in the list. Only installed interim fixes appear. The list includes fix ID name, build date, and the current applied state (installed). Click Details to obtain more detailed information about a selected interim 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 Enterprise product.
Use this panel to view prerequisite information when a selected 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 with the installation or uninstallation despite prerequisite failure.
Pre-installation 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-uninstallation Summary panel Use this panel to display a summary of interim fixes that are selected for uninstallation, and the WebSphere Application Server product to which each interim fix is currently applied.
Installation action Use this panel to view the progress of installing selected 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.
Uninstallation action Use this panel to view the progress of uninstalling selected fixes.
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 also go back and install additional interim fixes, which takes you to the Menu panel.
Post Uninstallation Summary panel Use this panel to view the results of the uninstallation. Depending on the result, this panel can display a success message, a failure message, or a canceled message. When the success message appears, the uninstallation process is complete. Click Finish to exit the panel. You can go back and uninstall additional interim fixes, which takes you to the Menu panel.
The WebSphere Application Server product contains structural differences from previous versions. 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. 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. The applied file has relevant information about the fixes or fix packs that are currently applied.
Event.history files 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. Beginning with Fix Pack 2, the time-stamped, detailed logs are in the install_root/logs/update directory.
This topic describes the XML data files that store product information for V5 WebSphere Application Server products. By default, the document type declarations (DTDs) for these files are in the properties/version/dtd folder of the installation root, or the server root directory. See the Storage locations section for more information.
This topic includes:
There are two kinds of product information files:
The following file indicates that a WebSphere Application Server V5 product is installed:
<?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:
<?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>
<?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"/>
This file stores version history information:
The following XML files in the /properties/version/history directory describe interim fixes that are currently installed. These XML files are related to installation items by the primary ID information, which is shown here by <angle brackets> and italicized text.
You can view product information by examining files in the install_root/properties/version directory, including the install_root/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 installation root bin directory.
The following report generation scripts extract data from XML data files in the properties/version folder.
Do not use the versionInfo command while installing or uninstalling the product, or while installing or uninstalling an interim fix.
Parameters:
Selects the format of the report. The default is TEXT.
Specifies the output file name. The report goes to standard output (stdout) by default.
Do not use the versionInfo command while installing or uninstalling the product, or while installing or uninstalling an interim fix.
The following report generation scripts extract data from XML data files in the install_root/properties/version/history folder:
Parameters:
Selects the format of the report. The default is TEXT.
Specifies the output file name. The report goes to standard output (stdout) by default.
WebSphere Application Server products use two other directories when performing update operations, for logging and backups. By default, the two directories are relative to the product version directory, as follows:
WebSphere Application Server products store log files to document component, interim fix and fix pack operations and updates.
Beginning with Fix Pack 2, the update installer stores its detailed log files in the install_root/logs/update directory.
WebSphere Application Server products back up components before applying interim fixes. If you uninstall an interim fix, WebSphere Application Server products restore the backed-up component JAR file.
For example: 20020924_211832 is 24-Sep-2002, 9:18:32 pm, GMT. All time stamps are in GMT.
For example: apar6789c is an fix ID; PTF_1 is a fix pack ID.
For example: properties/version/log/20020924_211832_apar6789c_install.log and properties/version/log/20020924_211912_apar6789c_uninstall.log
At Fix Pack 2 (V5.0.2) or later, the update installer creates these logs: install_root/logs/update/20020924_211832_apar6789c_install.log and install_root/logs/update/20020924_211912_apar6789c_uninstall.log
For example: 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 update installer creates these logs: install_root/logs/update/20020924_211832_apar6789c_ras_install.log and install_root/logs/update/20020924_211912_apar6789c_ras_uninstall.log
For example: properties/version/log/20020924_211832_PTF_1_install.log and properties/version/log/20020924_211912_PTF_2_uninstall.log
At Fix Pack 2 or later, the update installer creates these logs: install_root/logs/update/20030324_211832_was50_fp2_install.log and install_root/logs/update/20030325_211912_was50_fp2_uninstall.log
For example: properties/version/log/20020924_211832_PTF_1_ras_install.log and properties/version/log/20020924_211912_PTF_2_ras_uninstall.log
At Fix Pack 2 or later, the update installer 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
For example: 20020924_211832_apar6789c_ras_undo.jar
Do not delete a backup Java archive (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.
Product information files are located relative to the WebSphere Application Server product installation root, or the server root directory.
Default file paths and Java properties that set them are:
The version of the update installer that is bundled with Fix Pack 2 and later fix packs, stores log files in the install_root/logs/update directory.
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:
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 is placed to denote 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's 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 interim fix. The
id of the fix is embedded in the file name.
An efix file contains all fix data, such as description, a listing of
component updates, and prerequisite information.
Almost always, when installing an interim fix, all of the potential component
updates within the fix are required to be installed.
A separate application file must be examined to determine the components
which have been updated for a particular interim fix.
A list of custom properties may be provided. These are provided for
future use.
Element Detail:
efix.id The id of the interim fix.
efix.short-description A short description of the interim fix.
efix.long-description A long description of the interim fix.
efix.is-trial A flag indicating whether or not an interim fix is considered
a trial interim fix. Generally, a trial fix will be
followed up with a more permanent interim fix.
efix.expiration-date A date on which the fix is to be considered obsolete.
efix.build-version The build version of the interim fix. This is distinct from
the build version of component updates contained within
the interim fix.
efix-build-date The build date of the interim fix. This is distinct from the
build version of the component updates contained within
the interim fix.
efix.apar-info A list of APAR's which are associated with the interim fix.
efix.component-update A list of updates for components. For an interim 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 interim 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 fix may be installed.
This list may be empty, in which case the fix may be
installed on all platforms.
efix.product-prereq A list of products on which the fix may be installed.
This list may be empty, in which case the 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, omit certain potential component updates, but
only when the corresponding component is not installed.
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 provided 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-recomended 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-recomended 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 an interim fix, usually indicating that the 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 interim fix prerequisite instance denotes an interim fix that must be present (or, if negative,
must be absent) for the parent fix to be installed.
efix prerequisite instances may 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
- - The fixes may be installed 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 interim fix.
fix-prereq.is-negative A flag which indicates if the prerequisite
fix is required or prohibited. If false,
install the interim fix before installing
the parent interim fix. If true, do not install
the interim fix before you install the parent interim fix.
fix-prereq.install-index An optional index number 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 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 fix as specified by the efix id.
Element Detail:
efix-applied.efix-id The id of the 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 fix or fix pack to a particular component.
(The particular 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 flag which, when true, 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 which 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 the 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.
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 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 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 which was generated
for this event.
update-event.backup-name The name of the backup file which 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 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 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
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
which are updated.
enumEventAction.selective-uninstall Specifies that an event is an install
operation with a preset list of components
which 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.
The relevant terms and conditions, notices and other information are provided in the "LICENSE.TXT" file on the root directory of the first installation CD-ROM for the product that the update installer updates. Please note that any non-English version of the information in this file is unofficial and is provided to you for your convenience only. The English version of the file is the official version.
To see the most updated product information, please go to the WebSphere Application Server Library page
The following documentation is available when you use the update installer application:
The following terms are trademarks of IBM 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.
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.