Before using this information, be sure to read the general information under Appendix A. Notices.
Your feedback is important in helping to provide the most accurate and highest quality information.
Be sure to include the document name and number, the WebSphere Application Server version you are using, and, if applicable, the specific page, table, or figure number on which you are commenting.
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
This topic describes how to use the IBM Update Installer for WebSphere Software to install interim fixes, fix packs, and refresh packs. The Update Installer for WebSphere Software is also known as the Update Installer program, the UpdateInstaller program, and the Update installation wizard.
Use the proper authorizations to successfully install product updates.
When administrative security is enabled on WebSphere Application Server Network Deployment, for example, you must supply the administrative user ID and password before you can update the files.
Use the Update Installer program from the same installer ID that installed the product that you are updating. Otherwise, the file ownership mismatches might require correction by the root user.
The Update Installer wizard is an InstallShield for Multiplatforms wizard that runs with either a graphical user interface or in silent mode with a response file.
The following descriptions contain reference information about installing interim fixes, fix packs, and refresh packs on WebSphere Application Server products and components:
The Update Installer creates a backup file in the app_server_rootproperties/version/nif/backup directory.
IBM does not support restoring a backup file that you have modified.
Some maintenance packages provide required service for existing profiles in addition to service for the core product files. Each maintenance package that has profile maintenance provides a script that changes the profile. The Update Installer prompts you to back up your configuration when installing a maintenance package that has required maintenance for profiles.
Some maintenance packages provide optional service for existing profiles. The readme file for the maintenance package describes whether the maintenance package contains optional service for existing profiles. If so, the readme file describes how to use the script provided with the maintenance package.
Use the backupConfig command to back up the configuration of each profile that the maintenance package can update. Or archive the app_server_root/profiles directory to back up all of the profiles at once.
If you uninstall a maintenance package, the Update Installer does not uninstall the maintenance package from profiles. The reason for not removing the maintenance is that you might have configured the profile after installing the maintenance. To restore an original profile, use the restoreConfig command or copy the profile from the archived profile_root directory to replace the changed profile.
Apply the same maintenance packages to all of the WebSphere Application Server installations in a cluster. When all of the cluster members are not at the same service level, the following exception can occur:
DRSCacheApp E DRSW0008E: Exception is: com.ibm.disthub.impl.jms.JMSWrappedException: {-1361012295|unknown|java.io.OptionalDataException|}
This error can cause memory replication to not function properly.
Required information. The graphical interface requires you to supply the following information:
Field | Valid values | Description |
---|---|---|
File path of the installation
root directory of the WebSphere product or component.
Installation root directory of the Update Installer. See updi_root for more information. |
Identify the installation root directory for one of
the following products:
|
Download, unpack, and install the Update Installer for WebSphere Software. Or install the Update Installer that is on the WebSphere Application Server supplements disc. Install the Update Installer into each component that you intend to update. The Update Installer application updates the product in its parent directory by default. |
File name of the maintenance package to install. | Select a maintenance package to install from the maintenance directory. | The default maintenance package is the package with the latest date stamp and time stamp. |
The following procedure describes how to install a maintenance package. See Uninstalling maintenance packages for a description of how to roll back a maintenance package.
In addition, verify
that the umask setting is 022. To verify the umask setting, issue the following
command:
umask
To set the umask setting to 022, issue the following command:
umask 022
You have very likely already installed the software that you are now updating. But if not, install the software now.
Back up and uninstall any older copy of the Update Installer before downloading and installing the current Update Installer. To use a newer version of the Update Installer, you must first remove the older version.
Download maintenance packages for the Update Installer for WebSphere Software to install from the following IBM Web pages:
Before installing or uninstalling interim fixes, fix packs, and refresh packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WebSphere Application Server provides.
Stop all WebSphere Application Server-related Java processes that are running on the system where you are using the Update Installer program. For example, Java processes can include:
WebSphere Application Server processes include:
Stop all Java processes if necessary. If you install 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.
See the following technote for more information, Stop all WebSphere Application Server-related Java processes before using the Update Installer for WebSphere software.
The official statement of supported hardware and software is on the Supported hardware and software Web site.
Install the maintenance package on the deployment manager node before installing the maintenance package on each application server node that you intend to update.
Use the following command syntax to install the last maintenance package that you downloaded. The Update Installer wizard runs as a background process and does not display the graphical user interface when running in silent mode:
update.bat -silent -options responsefile
./update.sh -silent -options responsefile
Or, issue the update command to start the graphical user interface:
update.bat
./update.sh
The following tables show options that are available when using the update command.
The commands in the first table each start the Update Installer wizard with a graphical user interface. The command in the second table causes the Update Installer wizard to run in silent mode.
Command example | Type of installation | Description |
---|---|---|
update.bat | Graphical interface mode | Initializes the maintenance package field with the name
of the maintenance package that has the most recent date stamp and time stamp.
Accept all of the default values to install the maintenance package with the most recent time stamp. |
update.bat -options "responsefiles/file_name" | Graphical interface mode with an options file | Overrides all graphical interface values with values
that you specified in the options response file.
Always use a response file that is based on the response file under updi_root/responsefiles. |
update.bat -W maintenance.package="e: \IBM\WebSphere\AppServer \updateinstaller\maintenance\ PQ20029.pak" | Graphical interface mode | Overrides the name of the maintenance package to apply. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" | Graphical interface mode | Overrides the location of the WebSphere software to update. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" -W maintenance.package="e: \IBM\WebSphere\AppServer \updateinstaller\maintenance\ PQ20029.pak" | Graphical interface mode | Overrides the location of the WebSphere software to update and the name of the maintenance package to apply. |
Specify an appropriate JOBQ parameter value to have the job run in a different subsystem. Verify that the storage pool that the job runs in has as much memory as possible.
The command in the following table starts the Update Installer wizard in silent mode without the graphical user interface:
Command example | Type of installation | Description |
---|---|---|
update.bat -silent -options "responsefiles/file_name" | Silent mode with an options file | Overrides all default values with values that you specified
in the options response file.
Always use a response file that is based on the response file under updi_root/responsefiles. |
This procedure results in installing maintenance packages to update WebSphere software.
Click Relaunch on the last panel of the Update Installer to begin installing a second maintenance package.
After installing all maintenance packages, continue to use your WebSphere software.
The Update Installer for WebSphere Software can use an options response file to install maintenance packages from a command line interface.
The install.txt file has one directive that identifies the backup file for installing a service update. Comments in the file describe how to set the string value.
The Update Installer for WebSphere Software wizard reads the options file to determine installation choices. The Update Installer installs the maintenance package in silent mode instead of displaying a graphical user interface.
The sample options response file is named install.txt. The file is in the updi_root/responsefiles directory after you install the Update Installer for WebSphere Software into the installation root directory of the WebSphere software product.
The options file supplies the values to the Update installer wizard when installing silently. The wizard reads the options file to determine responses and does not display the graphical user interface.
The following command uses a copy of the options file named myresponsefile.txt to provide installation option responses during a silent installation:
./update.sh -options "responsefiles/myresponsefile.txt" -silent
If you do not use the -silent option, the wizard uses the response file to provide initial values for the graphical interface:
./update.sh -options "responsefiles/myresponsefile.txt"
In a silent installation, response file validation is coded into the installation. If the validation does not pass, the failure is recorded in the log files in the app_server_root/logs/update/tmp directory.
/opt/IBM/WebSphere/AppServer/updateinstaller/maintenance/PQ20029.pak
/opt/IBM/WebSphere/AppServer2
Edit the version of the file that is included in the Update Installer for WebSphere Software ZIP file. The following example is not guaranteed to be an accurate representation of the actual file.
################################################################################ # # This is the silent install response file for installing maintenance packages # using the update installer. # # A common use of an options file is to run the wizard in silent mode. This lets # the options file author specify wizard settings without having to run the # wizard in graphical or console mode. To use this options file for silent mode # execution, *uncomment* and modify the parameters defined within. # # Use the following command line when running the wizard from the update # installer directory: # # update -options responsefiles/install.txt -silent # # Please enclose all values within a single pair of double quotes. # ################################################################################ ################################################################################ # # Used to input the maintenance package full filename specification to be installed. # Edit as appropriate. # # ie. -W maintenance.package="C:\Program Files\IBM\WebSphere\AppServer\updateinstaller\maintenance\PQ20029.pak" # # Note: If no package is specified, a default of the last downloaded maintenance # package will be used (based on timestamp). # #-W maintenance.package= ################################################################################ # # Used to input the product install location that will be updated. # # ie. -W product.location="C:\Program Files\IBM\WebSphere\AppServer" # # Note: The product install location should always been specified, and it should # always be the full path. # -W product.location="<SPECIFY_PRODUCT_INSTALL_LOCATION_HERE>" ################################################################################ # # Do not edit these values. # # -W update.type="install"
This topic describes how to use the Update Installer for WebSphere Software to uninstall interim fixes, fix packs, and refresh packs. The Update Installer for WebSphere Software is also known as the update installer program, the updateInstaller program, and the Update installation wizard.
Use the proper authorizations to successfully uninstall product updates. Use the update installer program as the root user on a Linux or UNIX platform, or as the administrator on a Windows platform.
The Update Installer wizard is an InstallShield for Multiplatforms wizard that runs with either a graphical user interface or in silent mode with a response file.
The following descriptions contain reference information about uninstalling interim fixes, fix packs, and refresh packs on WebSphere Application Server products:
Do not launch multiple copies of the Update Installer wizard at one time: Concurrent launches of the update installer program are not supported. Performing more than one update at the same time can produce unpredictable results, which might include a failed or faulty installation.
Required information
The graphical interface requires the following information that you must supply:
Field | Valid values | Description |
---|---|---|
File path of the installation root directory of the WebSphere product and the Update Installer | Identify the installation root directory for one of
the following products:
|
The Update Installer application defaults to the last-visited product location. |
File name of the maintenance package to uninstall. | Select a maintenance package to uninstall from the app_server_root/properties/version/ update/backup directory. | The default maintenance package is the package with the latest date stamp and time stamp in the app_server_root /properties/version/ update/backup directory. |
The following procedure describes how to uninstall a maintenance package.
In addition, verify
that the umask setting is 022. To verify the umask setting, issue the following
command:
umask
To set the umask setting to 022, issue the following command:
umask 022
Before uninstalling interim fixes, fix packs, and refresh packs on a machine, stop all Java processes on the machine that use the IBM SDK, Java Technology Edition that WebSphere Application Server provides.
WebSphere Application Server processes include:
Stop all Java processes if necessary. If you uninstall a maintenance package while a WebSphere Application Server-related Java process runs, IBM does not guarantee that the product can continue to run successfully, or without error.
Uninstall the interim fix on each application server node in a cell before uninstalling the maintenance package from the deployment manager node.
Issue one of the following commands to uninstall with the graphical interface:
Command example | Type of installation | Description |
---|---|---|
update.bat -W update.type="uninstall" | Graphical interface mode | Initializes the maintenance package field with the name
of the maintenance package that was most recently installed.
Accept all of the default values to uninstall the maintenance package with the most recent date stamp and time stamp. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" -W update.type="uninstall" | Graphical interface mode | Overrides the graphical interface with the location of the WebSphere software to update. The default maintenance package to uninstall is the most recently installed maintenance package for that software. |
update.bat -W backup.package="PQ20029.pak" -W update.type="uninstall" | Graphical interface mode | Overrides the maintenance package field with the name of the maintenance package to uninstall. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" -W backup.package="PQ20029.pak" -W update.type="uninstall" | Graphical interface mode | Overrides the location of the WebSphere software to update and the name of the maintenance package to uninstall. |
update.bat -options "responsefiles/file_name" | Graphical interface mode with an options file | Overrides all default values with values that you specified
in the options response file.
If you omit either value from the response file, the default maintenance package is the installed package with the most recent date stamp and time stamp. The default software is the software installed in the parent directory. |
Issue the following command to use the silent interface:
Command example | Type of installation | Description |
---|---|---|
update.bat -silent -options "responsefiles/file_name" | Silent mode with an options file | Overrides all default values with values that you specified
in the options response file.
Always use a response file that is based on the response file under updi_root/responsefiles. |
This procedure results in uninstalling maintenance packages to update WebSphere software.
After uninstalling maintenance packages, you can continue to use the WebSphere software.
Rolling back changes to existing profiles: Some maintenance packages for WebSphere Application Server products, such as Refresh Pack 2, update existing profiles. If you roll back a maintenance package that contains a profile update, also use any undo scripts provided with the profile update script to roll back changes to the existing profiles.
The readme file for a maintenance package describes scripts that update and scripts that roll back profile fix levels. For example, Refresh Pack 2 for WebSphere Application Server includes required service for the JDBC resource provider templates in existing profiles. See the readme for the profile update and undo scripts for the JDBC-related update for more information.
Deleting profiles created by a service level that is now rolled back: See Profiles remain at the Version 6.0.2 level after roll back for a description of a limitation that requires profiles to be at the same service level or at a lower service level that the WebSphere Application Server product.
For example, suppose that you install Fix Pack 1 for Version 6.1 (Version 6.1.0.1), create a new profile, and then roll back Fix Pack 1. You must delete the profile that you created at the Version 6.1.0.1 level to avoid possible problems.
The Update Installer for WebSphere Software can use an options response file to uninstall maintenance packages from a command line interface.
The uninstall.txt file has one directive that identifies the backup file for uninstalling a service update. Comments in the file describe how to set the string value.
The Update Installer for WebSphere Software wizard reads the options file to determine uninstall choices. The Update Installer uninstalls the maintenance package in silent mode, instead of displaying a graphical user interface.
The sample options response file is named uninstall.txt. The file is in the updi_root/responsefiles directory after you unzip the Update Installer for WebSphere Software into the installation root directory of the WebSphere software product.
The options file supplies the values to the Update installer wizard when uninstalling silently. The wizard reads the options file to determine responses and does not display the graphical user interface.
The following command uses a copy of the options file named myresponsefile.txt to provide uninstall option responses during a silent uninstall:
./update.sh -options "responsefiles/myresponsefile.txt" -silent
If you do not use the -silent option, the wizard uses the response file to provide initial values for the graphical interface:
./update.sh -options "responsefiles/myresponsefile.txt"
In a silent uninstall, response file validation has been coded into the uninstall process. If the validation does not pass, the failure is recorded in the log files in the app_server_root/logs/update/tmp directory.
/opt/properties/version/nif/backup/maintenance_package_to_uninstall
Although uninstalling maintenance from another product is possible, always use the Update installer wizard from the directory structure of the product that you are updating if possible. Problems can occur when a mismatch between product SDKs occurs, for example.
Do not use this directive unless absolutely necessary.
/opt/IBM/WebSphere/AppServer2
Edit the version of the file that is included in the Update Installer for WebSphere Software ZIP file. The following example is not guaranteed to be an accurate representation of the actual file.
################################################################################ # # This is the silent install response file for uninstalling maintenance packages # using the update installer. # # A common use of an options file is to run the wizard in silent mode. This lets # the options file author specify wizard settings without having to run the # wizard in graphical or console mode. To use this options file for silent mode # execution, *uncomment* and modify the parameters defined within. # # Use the following command line when running the wizard from the update # installer directory: # # update -options responsefiles/uninstall.txt -silent # # Please enclose all values within a single pair of double quotes. # ################################################################################ ################################################################################ # # Used to input the maintenance backup package filename to be uninstalled. # This is the same filename as the package that was originally installed. # A maintenance package can only be uninstalled if a backup package exists. # # ie. -W backup.package="PQ20029.pak" # # Note: If no package is specified, a default of the last installed maintenance # package will be used. # #-W backup.package="" ################################################################################ # # Used to modify the product install location that will be updated. # This value should be left commented out if the Update Installer is # being run from the recommended location # # ie. -W product.location="C:\Program Files\IBM\WebSphere\AppServer" # # Note: The product install location should always been specified, and it should # always be the full path. # -W product.location="<SPECIFY_PRODUCT_INSTALL_LOCATION_HERE>" ################################################################################ # # Do not edit these values. # -W update.type="uninstall"
The update command is the Update Installer for WebSphere Software program. The Update installer wizard is also known as the Update installation wizard, the update installer program, and the updateInstaller program.
The update installer program installs and uninstalls interim fixes, fix packs, and refresh packs to update WebSphere software.
The update command calls the update installer program to install and uninstall service to update WebSphere software. This topic describes the update installer command and its command-line parameters.
The following descriptions contain reference information about the command.
See Installing maintenance packages and Uninstalling maintenance packages for information about using the command.
The following tables list commands for installing and uninstalling interim fixes.
Issue one of the following commands to use the graphical interface:
Command example | Type of installation | Description |
---|---|---|
update.bat | Graphical interface mode | Initializes the interim fix field with the name of the
interim fix that has the most recent date stamp and time stamp.
Accept all of the default values to install the interim fix with the most recent time stamp. |
update.bat -options "responsefiles/file_name" | Graphical interface mode with an options file | Overrides all graphical interface values with values
that you specified in the options response file.
If you omit either value, the default maintenance package is the one with the most recent date stamp and time stamp. The default software is the software installed in the parent directory. |
update.bat -W maintenance.package="e: \IBM\WebSphere\AppServer \updateinstaller\maintenance \PQ20029.pak" | Graphical interface mode | Overrides the name of the maintenance package to apply. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" | Graphical interface mode | Overrides the location of the WebSphere software to update. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" -W maintenance.package="e: \IBM\WebSphere\AppServer \updateinstaller\maintenance \PQ20029.pak" | Graphical interface mode | Overrides the location of the WebSphere software to update and the name of the maintenance package to apply. |
Issue the following command to use the silent interface:
Command example | Type of installation | Description |
---|---|---|
update.bat -silent -options "responsefiles/file_name" | Silent mode with an options file | Overrides all default values with values that you specified
in the options response file.
Always use a response file that is based on the response file under updi_root/responsefiles. |
Issue one of the following commands to uninstall with the graphical interface:
Command example | Type of installation | Description |
---|---|---|
update.bat -W update.type="uninstall" | Graphical interface mode | Initializes the interim fix field with the name of the
interim fix that was most recently installed.
Accept all of the default values to uninstall the interim fix with the most recent date stamp and time stamp. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" -W update.type="uninstall" | Graphical interface mode | Overrides the graphical interface with the location of the WebSphere software to update. The default interim fix to uninstall is the most recently installed interim fix for that software. |
update.bat -W backup.package="PQ20029.pak" -W update.type="uninstall" | Graphical interface mode | Overrides the interim fix field with the name of the maintenance package to uninstall. |
update.bat -W product.location="e: \IBM\WebSphere\AppServer" -W backup.package="PQ20029.pak" -W update.type="uninstall" | Graphical interface mode | Overrides the location of the WebSphere software to update and the name of the maintenance package to uninstall. |
update.bat -options "responsefiles/file_name" | Graphical interface mode with an options file | Overrides all default values with values that you specified
in the options response file.
If you omit either value from the response file, the default maintenance package is the installed package with the most recent date stamp and time stamp. The default software is the software installed in the parent directory. |
Issue the following command to use the silent interface:
Command example | Type of installation | Description |
---|---|---|
update.bat -silent -options "responsefiles/file_name" | Silent mode with an options file | Overrides all default values with values that you specified
in the options response file.
Always use a response file that is based on the response file under updi_root/responsefiles. |
The following sections describe logging that occurs when installing and uninstalling service.
If no installation log file exists, refer to the temporary log file in the updi_root/logs/update/tmp directory. If all validations pass, the installation occurs.
Then the update installer program creates the app_server_root/logs/update/maintenance_package.install directory.
Within the directory are the updatelog.txt file, the compressed updatetrace.log.gz file, and the compressed updateconfig.log.gz file. The updateconfig.log.gz file exists only when the installation of service uses the internal configuration manager utility to run ANT scripts.
If no log file exists after uninstalling an interim fix, refer to the temporary log file in the updi_root/logs/update/tmp directory. If all validations pass, the uninstall procedure occurs.
Then the update installer program creates the app_server_root/logs/update/maintenance_package.uninstall directory.
Within the directory are the updatelog.txt file, the compressed updatetrace.log.gz file, and the compressed updateconfig.log.gz file. The updateconfig.log.gz file exists only when the removal of service uses the internal configuration manager utility to run ANT scripts.
The log file includes an indicator of success:
This topic describes known problems and issues associated with the Update Installer for WebSphere Software program.
The update installer program displays its version information in the title bar of the graphical interface. Version information is stored in the version.txt file in the updateinstaller directory.
A new version might ship to correspond to any new fix. Information in the version.txt file is displayed prominently in the title bar of the wizard and is also recorded in the updatelog.txt file.
Always download and use the latest version of the Update installer wizard when installing an interim fix.
The Update Installer can not automatically detect locks on files by remote processes. So you must ensure that all AppServers processes have been stopped for all your profiles, including any remote profiles.
The versionInfo command generates a report from data extracted from XML files in the properties/version folder. The report includes a list of changed components and installed or uninstalled maintenance packages.
The versionInfo tool displays important data about the product and its installed components, such as the build version and build date. History information for installation and removal of maintenance packages also displays in the report. This tool is particularly useful when working with support personnel to determine the cause of any problem.
Product version reports
The following report generation scripts extract data from XML data files in the properties/version folder:
Lets you use parameters to create a version report.
Generates the versionReport.html report file in the current working directory, which is usually the bin directory.
The versionInfo command is a script.
The command file is a script named versionInfo.sh in
the app_server_root/bin directory.
The command file is named versionInfo.bat in
the app_server_root\bin directory.
The command syntax is:
versionInfo.sh [ -format text | html ] [ -file file_name ] [ -long ] [ -maintenancePackages ] [ -maintenancePackageDetail ] [ -components ] [ -componentDetail ] versionInfo [ -help | /help | -? | /? | -usage ]
Issue the command from the app_server_root/bin directory.
The command syntax is:
versionInfo [ -format text | html ] [ -file file_name ] [ -long ] [ -maintenancePackages ] [ -maintenancePackageDetail ] [ -components ] [ -componentDetail ] versionInfo [ -help | /help | -? | /? | -usage ]
Issue the command from the app_server_root\bin directory.
The versionInfo command reports the following information:
Displays the following general information about the current installation:
Displays a list of installed WebSphere products:
This information and the other information topic descriptions are hierarchal for each installed product, component, component update, installed maintenance package, included APARs, and component updates.
This section of the report displays the following information:
Displays the following component-level information of the installed component from the .component file under the /properties/version directory:
Displays the general maintenance package information:
Displays the general maintenance package information:
Displays the list of APARs fixed by this maintenance package.
Displays the following information about each component that is updated by the installed maintenance package:
When the WebSphere Application Server 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 2005-05-18 15:58:40-0400 Installation ---------------------------------------- Product Directory: /opt/WebSphere/AppServer Version Directory: /opt/WebSphere/AppServer/properties/version DTD Directory: /opt/WebSphere/AppServer/properties/version/dtd Log Directory: /opt/WebSphere/AppServer/logs/update Backup Directory: /opt/WebSphere/AppServer/properties/version/backup TMP Directory: /tmp Installation Platform ---------------------------------------- Name IBM WebSphere Application Server Version 6.0 Product List ---------------------------------------- BASE installed Installed Product ---------------------------------------- Name IBM WebSphere Application Server Version 6.0.1 ID BASE Build Level m0451.03 Build Date 12/19/2004 Installed Component --------------------------------------------------- Component Name: activity.impl Spec Version: 6.0 Build Version: m0451.03 Build Date: 12/19/04 Installed Component Update ---------------------------------------------------- Component Name: activity.impl Update Type: maintenance package Maintenance Package ID: was60_fp1_linux Update Effect: replace Log File Name: /opt/WebSphere/AppServer/logs/update/was60_fp1_linux.install/updatelog.txt Backup File Name: /opt/WebSphere/AppServer/properties/version/backup/was60_fp1_linux.pak Timestamp: 2004-12-17 18:24:34-0500 Installed Component Update ----------------------------------------------------- Component Name: activity.impl Update Type: maintenance package Maintenance Package ID: was60_fp2 Update Effect: replace Log File Name: /opt/WebSphere/AppServer/logs/update/was60_fp2_linux.install/updatelog.txt Backup File Name: /opt/WebSphere/AppServer/properties/version/backup/was60_fp2_linux.pak Timestamp: 2004-12-19 06:24:34-0500 Installed Component ----------------------------------------------------- Component Name: activity.session Spec Version: 6.0 Build Level: m0451.03 Build Date: 12/19/04 Installed Component Update ----------------------------------------------------- Component Name: activity.session Update Type: maintenance package Maintenance Package ID: was60_fp2 Update Effect: replace Log File Name: /opt/WebSphere/AppServer/logs/update/was60_fp2_linux.install/updatelog.txt Backup File Name: /opt/WebSphere/AppServer/properties/version/backup/was60_fp2_linux.pak Timestamp: 2004-12-19 06:24:34-0500 Installed Maintenance Package ----------------------------------------------------- Maintenance Package ID: was60_fp1_linux Description: IBM WebSphere Application Server, Version 6.0.1 Fix Pack for Linux Build Date: 12/17/2004 Included Apars ----------------------------------------------------- PQ12345 Component Updates ----------------------------------------------------- activity updated installed on 2004-12-17 06:24:30-0500 Installed Maintenance Package ----------------------------------------------------- Maintenance Package ID: was60_fp2 Description: IBM WebSphere Application Server, Version 6.0.2 Fix Pack for Linux Build Date: 12/19/2004 Included Apars ----------------------------------------------------- PQ12345 PQ23456 PQ34567 Component Updates ------------------------------------------------------ activity updated installed on 2004-12-19 06:24:30-0500 activity.impl updated installed on 2004-12-19 06:24:30-0500 ----------------------------------------------------- End Installation Status Report -----------------------------------------------------
Changes are in two areas: command syntax and report information.
The following changes are in effect:
The following changes are in effect:
The historyInfo command generates a report from data extracted from XML files in the properties/version folder and the properties/version/history folder. The report includes a list of changed components and a history of installed or uninstalled maintenance packages.
The historyInfo tool displays important data about the product and its installed components, such as the build version and build date. History information for installation and removal of maintenance packages also displays in the report. This tool is particularly useful when working with support personnel to determine the cause of any problem.
Product history reports
The following report generation scripts extract data from XML data files in the properties/version folder and the properties/version/history folder:
Lets you use parameters to create a history report.
Generates the historyReport.html report file in the current working directory, which is usually the bin directory.
The historyInfo command is a script.
The command file is a script named genHistoryReport.sh in
the app_server_root/bin directory.
The command file is a script named genHistoryReport.bat in
the app_server_root\bin directory.
The command syntax is:
historyInfo.sh [ -format text | html ] [ -file file_name ] [ -maintenancePackageID ID_of_maintenance_package ] [ -component component_name ] historyInfo [ -help | /help | -? | /? | -usage ]
Issue the command from the app_server_root/bin directory.
The command syntax is:
historyInfo [ -format text | html ] [ -file file_name ] [ -maintenancePackageID ID_of_maintenance_package ] [ -component component_name ] historyInfo [ -help | -? | /help | /? | -usage ]
Issue the command from the app_server_root\bin directory.
The historyInfo command reports the following information:
Displays the following general information about the current installation:
Displays the list of installed maintenance packages (interim fix, fix pack, and refresh pack) and the following related information:
Displays the following component-level information of the event for the current maintenance package:
The historyInfo command also generates the event.history file. This file represents the raw data of the history report information. The following example of an event.history file corresponds to the history report in the preceding example:
<!DOCTYPE event-history SYSTEM "eventHistory.dtd"> <event-history> <update-event event-type="ptf" id="was60_fp1_linux" update-action="install" primary-content="was60_fp1_linux.pak" update-type="replace" log-name= "/opt/WebSphere/AppServer/logs/update/was60_fp1_linux.install/updatelog.txt" backup-name= "/opt/WebSphere/AppServer/properties/version/backup/was60_fp1_linux.pak" start-time-stamp="2004-12-14 06:15:14-0500" result="success"> <update-event event-type="component" parent-id="was60_fp1_linux" id="activity" update-action="install" update-type="replace" start-time-stamp="2004-12-14 06:15:14-0500" result="success"> </update-event> <update-event event-type="component" parent-id="was60_fp1_linux" id=" activity.impl" update-action="install" update-type="replace" start-time-stamp="2004-12-14 06:15:14-0500" result="success"> </update-event> </update-event> <update-event event-type="ptf" id="was60_fp2" update-action="install" primary-content="was60_fp1_linux.pak" update-type="replace" log-name="/opt/WebSphere/AppServer/logs/update/was60_fp2.install/updatelog.txt" backup-name="/opt/WebSphere/AppServer/properties/version/backup/was60_fp2.pak" start-time-stamp="2004-12-14 10:25:34-0500" result="partialSuccess"> <update-event event-type="component" parent-id="was60_fp2" id="activity" update-action="install" update-type="replace" start-time-stamp="2004-12-14 10:25:34-0500" result="partialSuccess"> </update-event> <update-event event-type="component" parent-id="was60_fp2" id=" activity.impl" update-action="install" update-type="replace" start-time-stamp="2004-12-14 10:25:34-0500" result="partialSuccess"> </update-event> </update-event> <update-event event-type="ptf" id="was60_fp2" update-action="uninstall" primary-content=" was60_fp2.pak" update-type="replace" log-name= "/opt/WebSphere/AppServer/logs/update/was60_fp2.uninstall/updatelog.txt" backup-name="not applicable" start-time-stamp="2004-12-18 17:29:12-0500" result="partialSuccess"> <update-event event-type="component" parent-id="was60_fp2" id="activity" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-18 17:29:12-0500" result="partialSuccess"> </update-event> <update-event event-type="component" parent-id="was60_fp2" id=" activity.impl" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-18 17:29:12-0500" result="partialSuccess"> </update-event> </update-event> <update-event event-type="ptf" id="was60_fp1_linux" update-action="uninstall" primary-content=" was60_fp1_linux.pak" update-type="replace" log-name= "/opt/WebSphere/AppServer/logs/update/was60_fp1_linux.install/updatelog.txt" backup-name="not applicable" start-time-stamp="2004-12-23 15:15:14-0500" result="faiurel"> <update-event event-type="component" parent-id="was60_fp1_linux" id="activity" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-23 15:15:14-0500" result="failure"> </update-event> <update-event event-type="component" parent-id="was60_fp1_linux" id=" activity.impl" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-23 15:15:14-0500" result="failure"> </update-event> </update-event> </event-history>
Changes are in three areas: command syntax, report information, and the event.history file.
Version 6 replaces the term updateID with maintenancePackageID to describe a specific maintenance package. This matches the terminology used in the Version 6 update installer application.
The following changes are in effect:
The following changes are in effect:
The genHistoryReport command generates the historyReport.html report file in the current working directory, which is usually the bin directory. The report includes a list of changed components and installed or uninstalled maintenance packages. The genHistoryReport script invokes the historyInfo script specifying the correct parameters to place the information generated into an HTML file in the current directory.
The historyInfo tool displays historical data about the product and the installation and removal of maintenance packages for the product. This tool is particularly useful when working with support personnel to determine the cause of any problem.
Product history reports
The following report generation scripts extract data from XML data files in the properties/version folder and the properties/version/history folder:
Lets you use parameters to create a history report.
Generates the historyReport.html report file in the current working directory, which is usually the bin directory. The report includes a list of components, fixes, fix packs, and refresh packs.
The command file is a script.
The command file is named genHistoryReport.sh in
the app_server_root/bin directory.
The command file is named genHistoryReport.bat in
the app_server_root\bin directory.
The command syntax is:
genHistoryReport.sh
Issue the command from the app_server_root/bin directory.
The command syntax is:
genHistoryReport.bat
Issue the command from the app_server_root\bin directory.
The historyInfo command generates the report. The genHistoryReport command calls the historyInfo command with a set of report parameters that reports the following information:
Installation information displays the following general information about the current installation:
Installation event information displays the list of installed maintenance packages (interim fix, fix pack, and refresh pack) and the following related information:
Component installation event information displays the following component-level information of the event for the current maintenance package:
The genHistoryReport command also generates the event.history file. This file represents the raw data of the history report information. The following example of an event.history file corresponds to the history report in the preceding example:
<!DOCTYPE event-history SYSTEM "eventHistory.dtd"> <event-history> <update-event event-type="ptf" id="was60_fp1_linux" update-action="install" primary-content="was60_fp1_linux.pak" update-type="replace" log-name= "/opt/WebSphere/AppServer/logs/update/was60_fp1_linux.install/updatelog.txt" backup-name= "/opt/WebSphere/AppServer/properties/version/backup/was60_fp1_linux.pak" start-time-stamp="2004-12-14 06:15:14-0500" result="success"> <update-event event-type="component" parent-id="was60_fp1_linux" id="activity" update-action="install" update-type="replace" start-time-stamp="2004-12-14 06:15:14-0500" result="success"> </update-event> <update-event event-type="component" parent-id="was60_fp1_linux" id=" activity.impl" update-action="install" update-type="replace" start-time-stamp="2004-12-14 06:15:14-0500" result="success"> </update-event> </update-event> <update-event event-type="ptf" id="was60_fp2" update-action="install" primary-content="was60_fp1_linux.pak" update-type="replace" log-name="/opt/WebSphere/AppServer/logs/update/was60_fp2.install/updatelog.txt" backup-name="/opt/WebSphere/AppServer/properties/version/backup/was60_fp2.pak" start-time-stamp="2004-12-14 10:25:34-0500" result="partialSuccess"> <update-event event-type="component" parent-id="was60_fp2" id="activity" update-action="install" update-type="replace" start-time-stamp="2004-12-14 10:25:34-0500" result="partialSuccess"> </update-event> <update-event event-type="component" parent-id="was60_fp2" id=" activity.impl" update-action="install" update-type="replace" start-time-stamp="2004-12-14 10:25:34-0500" result="partialSuccess"> </update-event> </update-event> <update-event event-type="ptf" id="was60_fp2" update-action="uninstall" primary-content=" was60_fp2.pak" update-type="replace" log-name= "/opt/WebSphere/AppServer/logs/update/was60_fp2.uninstall/updatelog.txt" backup-name="not applicable" start-time-stamp="2004-12-18 17:29:12-0500" result="partialSuccess"> <update-event event-type="component" parent-id="was60_fp2" id="activity" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-18 17:29:12-0500" result="partialSuccess"> </update-event> <update-event event-type="component" parent-id="was60_fp2" id=" activity.impl" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-18 17:29:12-0500" result="partialSuccess"> </update-event> </update-event> <update-event event-type="ptf" id="was60_fp1_linux" update-action="uninstall" primary-content=" was60_fp1_linux.pak" update-type="replace" log-name= "/opt/WebSphere/AppServer/logs/update/was60_fp1_linux.install/updatelog.txt" backup-name="not applicable" start-time-stamp="2004-12-23 15:15:14-0500" result="faiurel"> <update-event event-type="component" parent-id="was60_fp1_linux" id="activity" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-23 15:15:14-0500" result="failure"> </update-event> <update-event event-type="component" parent-id="was60_fp1_linux" id=" activity.impl" update-action="uninstall" update-type="replace" start-time-stamp="2004-12-23 15:15:14-0500" result="failure"> </update-event> </update-event> </event-history>
Changes are in three areas: command syntax, report information, and the event.history file.
Version 6 replaces the term updateID with maintenancePackageID to describe a specific maintenance package. This matches the terminology used in the Version 6 update installer application.
The following changes are in effect:
The following changes are in effect:
The genVersionReport command uses the versionInfo command to generate the versionReport.html report file in the current working directory, which is usually the bin directory. The report includes a list of changed components and installed or uninstalled maintenance packages. The genVersionReport script invokes the versionInfo script specifying the correct parameters to place the information generated into an HTML file in the current working directory.
The versionInfo tool displays important data about the product and its installed components, such as the build version and build date. History information for installation and removal of maintenance packages also displays in the report. This tool is particularly useful when working with support personnel to determine the cause of any problem.
Product version reports
The following report generation scripts extract data from XML data files in the properties/version folder:
Use the versionInfo command to specify your own report parameters when creating a customized version report.
Use the genVersionReport command to generate the versionReport.html report file in the current working directory, which is usually the bin directory. The report includes the list of components, fixes, fix packs, and refresh packs.
The genVersionReport command is a script.
The command file is named genVersionReport in the bin directory of the app_server_root directory.
The command syntax is:
genVersionReport.sh
genVersionReport.bat
Issue the command from the bin directory of the app_server_root directory.
The versionInfo command reports the following information:
Displays the following general information about the current installation:
Displays a list of installed WebSphere products:
This information and the other information topic descriptions are hierarchal for each installed product, component, component update, installed maintenance package, included APARs, and component updates.
This section of the report displays the following information:
Displays the following component-level information of the installed component from the .component file in the app_server_root/properties/version directory:
Displays the general maintenance package information:
Displays the general maintenance package information:
Displays the list of APARs fixed by this maintenance package.
Displays the following information about each component that is updated by the installed maintenance package:
Changes are in two areas: command syntax and report information.
The following changes are in effect:
The following changes are in effect:
The WebSphere Application Server product contains structural differences from previous versions. The properties/version directory in the app_server_root contains important data about the product and its installed components, such as the build version and build date. This information is included in WAS.product and [component].component files.
Run the historyInfo command to create a report about installed maintenance packages. The historyInfo command creates a report on the console and also creates tracking files in the app_server_root/properties/version/history directory.
Time-stamped, detailed logs record each update process in the properties/version/log directory of the app_server_root.
This topic describes the XML data files that store product information for Version 6 WebSphere Application Server products. By default, the document type declarations (DTDs) for these files are in the properties/version/dtd folder of the app_server_root, or the server root directory. See the Product version information section for more information.
This topic includes the following sections:
XML files in the properties/version directory that store version information:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE websphere PUBLIC "websphereId" "websphere.dtd"> <websphere name="IBM WebSphere Application Server" version="6.1"/>
The following XML files in the properties/version directory represent installed items and installation events such as product edition, version, component, and build information.
For example, <id>ND</id>.product 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 - ND"> <id>ND</id> <version>6.1.0</version> <build-info date="02/03/06" level="s0461.18"/> </product>
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE component PUBLIC "componentId" "component.dtd"> <component build-date="05/31/06" build-version="a0522.07" name="activity" spec-version="6.1.0.0"/>
XML files in the properties/version/history directory that store version history information files:The following XML files in the properties/version/history directory describe refresh packs, fix packs, and interim fixes 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.
WebSphere Application Server provides the ability to generate Version reports and History reports from the data in the files. The following report-generation scripts are available in the app_server_root bin directory.
Product version reports
The following report generation scripts extract data from XML data files in the properties/version folder:
Lets you use parameters to create a version report on Linux and UNIX platforms, or on Windows platforms.
Generates the versionReport.html report file in the bin directory on Linux and UNIX platforms, or on Windows platforms. The report includes the list of components and installed and uninstalled maintenance packages.
Product history reports
The following report generation scripts extract data from XML data files in the properties/version/history folder:
Lets you use parameters to create a history report on Linux and UNIX platforms, or on Windows platforms.
Generates the historyReport.html report file in the bin directory on Linux and UNIX platforms, or on Windows platforms. The report includes the list of components and a history of installed and uninstalled maintenance packages.
WebSphere Application Server products use two other directories when performing update operations, for logging and backups:
The location of log files that describe events that occur during the use of the update installer program.
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
For example: 20050324_211832 is 24-Mar-2004, 9:18:32 pm, GMT. All time stamps are in GMT.
For example: apar6789c is an interim fix ID; PTF_1 is a fix pack ID.
For example, the Update installer program creates these logs: app_server_rootlogs/update/20050324_211832_apar6789c_install.log and app_server_root/logs/update/ 20050324_211912_apar6789c_uninstall.log
For example, the update installer program creates these logs: app_server_root/logs/update/20050324_211832_apar6789c_ras_install.log and app_server_root/logs/update/ 20050324_211912_apar6789c_ras_uninstall.log
For example, the update installer program creates these logs: app_server_root/logs/update/20050924_211832_was60_fp1_install.log and app_server_root/logs/update/ 20050924_211912_was60_fp1_uninstall.log
For example, prior to Fix Pack 2: properties/version/log/20050324_211832_was50_fp1_ras_install.log and properties/version/log/20030325_211912_was50_fp1_ras_uninstall.log
The update installer program creates these logs: app_server_root/logs/update/20050324_211832_was60_fp1_ras_install.log and app_server_root/logs/update/20030325_211912_was60_fp1_ras_uninstall.logFor 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.
Product information files are located relative to the WebSphere Application Server product app_server_root, or the server root directory.
Default file paths are:
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
name string required version string required
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/WAS.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. Type Family: update File Types: ptf ptf-applied File Type: ptf Persistence: versionDir/id.ptf Elements: id string required short-description string required build-version string required build-date date required component-name complex min=1, max=unbounded Type Detail: A ptf file denotes the presence of some portion of a specific refresh pack, fix pack, or interim fix. The id of the refresh pack, fix pack, or interim fix is embedded in the fix pack file name. A ptf file contains a listing of component updates. When installing a refresh pack, fix pack, or interim fix, you can omit certain potential component updates, but only when the corresponding component is not installed. Examine a separate application file to determine the components that a particular refresh pack, fix pack, or interim fix updates. A refresh pack or fix pack can include updates for a number of interim fixes. Element Detail: ptf.id The ID of the fix pack. ptf.short-description A short 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-name A list of components. 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 refresh pack, fix pack, or interim fix as specified by the ID. Element Detail: ptf-applied.ptf-id The ID of the refresh pack, fix pack, or interim fix 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] log-name anyURL required backup-name anyURL required time-stamp date required Type Detail: An applied instance is present to indicate the application of an update for a particular interim fix, fix pack, or refresh pack to a particular component. (The particular interim fix, fix pack, or refresh pack is specified by the applied 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.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). 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 refresh pack, fix pack, and interim fix 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] primary-content anyURI required update-action enum required [enumEventAction] log-name anyURI required backup-name anyURI required start-time-stamp dateTime required result string required update-event complex optional Type Detail: An update event denotes a single update action, applying to either a fix, a fix pack, a refresh pack, or a component, according to the set event type. Element Detail: update-event.event-type The type of this event, either a refresh pack, fix pack, or an interim fix 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, fix pack, or refresh pack of this event. update-event.id The ID of the interim fix, fix pack, refresh pack, or component that was updated, interpreted according to the type of the event. update-event.update-type The type of update for an update event. update-event.update-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.result The result of the 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. Type Detail: An event type instance specifies the type of an update event, which is either a refresh pack, fix pack, or interim fix (ptf) event or a component event. The interpretation of particular event elements depends on the set event type. Value Detail: EventType.ptf Specifies that an event is for a refresh pack, fix pack, or interim fix update. EventType.component Specifies that an event is for a component update. Enum Type: update-action Values: 0 Install 1 Uninstall Type Detail: An event action instance specified the operation performed by an update, which can be an install or uninstall operation. Value Detail: enumEventAction.install Specifies that an event is an install operation. enumEventAction.uninstall Specifies that an event is an uninstall operation. 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.
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:
For trademark attribution, visit the IBM Terms of Use Web site (http://www.ibm.com/legal/us/).