Maintenance - PureApplication

Maintenance - PureApplication

+
Search Tips | Advanced Search

Overview
Manage emergency fixes

Add emergency fixes
Packaging emergency fixes

service.xml

Delete emergency fixes
Fields on the Emergency Fixes pane

Upgrade virtual systems

Virtual system instance maintenance
Add DB2 fix packs
Delete DB2 fix packs
Upgrade Advanced Middleware Configuration

Upgrade in a deployed image
Upgrade by migrating data from an image of the previous version
Update script packages

Upgrade shared service instances
Upgrade the external PureApplication System Agent
Clear resources in javaws cache

Overview

To perform these steps you must be assigned the Hardware administration role with permission to Manage hardware resources (Full permission)
Access the system maintenance report to view current details about the system, such as the machine type models (MTMs) and serial numbers, device types, firmware levels, and field replaceable unit (FRU) serial numbers. In the system console, click...
System | Settings | System Maintenance Report

You can choose too...

Download and save the preceding details to a CSV file.
Download SGEN log files.

Manage emergency fixes

You can use the console to apply emergency fixes, which apply code updates to deployed instances such as virtual applications, virtual systems, databases, and shared services. You can complete these tasks if you have the Workload resources administration with full permissions.

Add emergency fixes to the catalog

Emergency fixes are used to update the product binaries of deployed instances. Emergency fixes can be individual fixes or a group of fixes that are associated with particular virtual system or virtual application types. You must have the Create new catalog content permission or the Workload resources administration with full permissions to complete this task. Emergency fixes are provided by IBM or an image provider and must be downloaded before you can add them to the catalog. Download fixes from IBM PureSystems Centre. It is also possible to package the own fix to apply custom maintenance to the virtual system instances.

Click...
Catalog | Emergency Fixes | New

Enter the emergency fix name in the Name field.
Click OK.
Click Browse and select a file to upload. Click OK. For security reasons, only .zip, .tgz and .pak files can be uploaded.
Click Upload to import the file.
Optional: Click Add more and select a user name to grant additional users access to the emergency fix.
You are automatically assigned access to an emergency fix when you create it. If you want to allow additional users to apply this fix to various instances, you must grant the users access.
Select a severity level for the fix. This field is informational and identifies the urgency for applying this emergency fix.
Select virtual images or plug-ins for which this emergency fix is applicable.
The Applicable to field determines to which virtual images or plug-ins this emergency fix applies. This fix is only available for the instances that you created using the virtual images that are listed in this field. If the plug-ins are selected, the fix is only available to the selected plug-ins.
To view the virtual images listed in the Applicable to field, you must have read access to the images in addition to having the Create new catalog content user permission.
You might find that the applicable software list for an uploaded emergency fix is incomplete. When you add an emergency fix to the catalog, any virtual images or plug-ins that are defined as prerequisites are automatically selected as applicable software for the emergency fix in the Applicable to list. When multiple prerequisites are defined in the package that you upload, it can take some time for the Applicable to list to update. Click Refresh in the browser to refresh and view the most current list.
When you create a virtual application pattern in the Virtual Application Builder, a WebSphere Application Server interim fix is available to include in the virtual application if the following conditions are met:

The virtual application pattern is based on a pattern type that is associated with one of the plug-ins you selected in the Applicable to field.
The plug-in is enabled.

Other types of fixes are applied using the maintenance fix feature in the Virtual Application Console.

What to do next

Apply the emergency fixes to the environment.

Package emergency fixes

In addition to IBM provided emergency fixes, you can create the own archives to be uploaded and used as an emergency fix to apply maintenance to instances.
To add content to the catalog, you must be assigned the Create new catalog content permission or the Workload resources administration with full permissions. When you construct the emergency fix, be aware that all emergency fixes must be less than 2 GB. If an archive file exceeds this limit, the upload fails.
When you prepare an emergency fix, include the following artifacts:

A script to install the fix.
An XML file, named service.xml, that provides information about the fix to IBM PureApplication System. The file must be in the root directory of the archive.

Emergency fixes for transformers are not currently supported. You can update plug-in lifecycle scripts by using the maintenance operation on the Virtual Application Console.

Create a script or module to run on the virtual system instance.
This script can be used to perform a wide variety of tasks on the virtual system instance. Although designed for maintenance purposes, you can use this packaging to run custom scripts or modules. When you design the script, remember that each emergency fix must be less than 2 GB. Scripts for a virtual system instance can be run only once.
Create a service.xml file for the fix.
Package the files for the emergency fix into an archive that you can upload to the system
The archive must include the service.xml file, the script that you created to deploy the fix, and any other artifacts required for deploying the fix. The following archive formats are supported: .zip, .tgz, and .tar.gz.

After you complete these packaging steps, you can use the resulting archive file to add a custom emergency fix to the catalog.

service.xml
<?xml version="1.0" encoding="UTF-8"?>

<rmsd:Service xmlns="xmlschema_url" 
              xmlns:xsi="xmlschema_instance_url"
              xmlns:rmsd="service_description"
              xsi:schemaLocation="schema_location"> 

  <rmsd:ImagePrereqs> 
    <rmsd:prereq name="image_name" 
                 version="image_version"/>
  </rmsd:ImagePrereqs>

  <rmsd:Packages>

    <rmsd:Package name="package_name" 
                  type="ifix"  
                  target="APPLICATION">

      <rmsd:EnvVariables>
        <rmsd:EnvVariable key="var1_name"
                          defaultValue="default1_value"
                          type="var1_type">
        </rmsd:EnvVariable>
        <rmsd:EnvVariable key="var2_name"
                          defaultValue="default2_value"
                          type="var2_type">
        </rmsd:EnvVariable>
      </rmsd:EnvVariables>

      <rmsd:Command name="script command">
        <rmsd:Arguments>
           <rmsd:Argument><arg1></rmsd:Argument>
           <rmsd:Argument><arg2></rmsd:Argument>
        </rmsd:Arguments>
        <rmsd:Log><log_directory></rmsd:Log>
        <rmsd:Location><script_location></rmsd:Location>
        <rmsd:Timeout><timeout_value_ms></rmsd:Timeout>
      </rmsd:Command>

    </rmsd:Package>

  </rmsd:Packages>
</rmsd:Service>
The rmsd:Service section defines the overall xml file, including URL pointers to the schema information:

<xmlschema_url> (Example: http://www.w3.org/2001/XMLSchema)
<xmlschema_instance_url> (Example: http://www.w3.org/2001/XMLSchema-instance)
<service_description (Example: http://www.ibm.com/websphere/rainmaker/service/servicedescription
<schema_location (Example: http://www.ibm.com/websphere/rainmaker/service/servicedescription ./Service.xsd

Each additional section of the service.xml file describes information about the emergency fix and deployment requirements, and is included in the service.xml file depending on the target for the emergency fix.

The ImagePrereqs section

For emergency fixes that apply to a virtual image, specify prerequisites in the rmsd:ImagePrereqs section. These prerequisites include the operating system base images. You can specify multiple virtual images. If this information is not specified in service.xml, you must select the applicable images and versions in the Images list in Applicable To field of the catalog emergency fix panel.
For each image, specify the following attributes:

name

The name of the virtual image to which this emergency fix applies.

version

The version of the virtual image to which this emergency fix applies.

A typical rmsd:ImagePrereqs section is similar to the following example:
<rmsd:ImagePrereqs>
  <rmsd:prereq name="WebSphere Application Server 7.0.0.3" version="7.0.0.3"/>
</rmsd:ImagePrereqs>
The PluginPrereqs section

For fixes that can be applied to particular role in a virtual application plug-in, you must specify the plug-in name and version in the rmsd:PluginPrereqs section. If this information is not specified in service.xml, you must select the applicable plug-in and version in the Plugins list in Applicable To field of the catalog emergency fix panel.
For each image, specify the following attributes:

pluginname

The name of the plug-in to which this emergency fix applies.

pluginvrmf

The version of the plug-in to which this emergency fix applies.

A typical rmsd:PluginPrereqs section is similar to the following example:
<rmsd:PluginPrereqs>
  <rmsd:prereq pluginname="caching" pluginvrmf="2.0.0.3" /> 
</rmsd:PluginPrereqs>
Ensure that the values for these plug-in attributes exactly match the name and version of the plug-in to which the fix applies.

The Package section

Information about the emergency fix itself is specified in the rmsd:Package section.
The following attributes are supported for an emergency fix applied to either a virtual system or a virtual application:
Package
The name, type, and target of the archive file:

name

The name of the package. Example: name="IFPK12345"

type

The type of package. The only supported value is type="ifix".

target

The target of the package. The only supported value is target="APPLICATION".

Example:
<rmsd:Package name="IFPK12345" type="ifix"  target="APPLICATION">
Command name
The command line to run the script. Example:
<rmsd:Command name="/bin/sh /tmp/update/installAppService.sh">
Arguments
This attribute is nested inside the Command attribute and specifies one or more arguments that are passed to the script when it is executed. Example:
<rmsd:Arguments>
  <rmsd:Argument><arg1></rmsd:Argument>
  <rmsd:Argument><arg2></rmsd:Argument>
</rmsd:Arguments>
Location
This attribute is nested inside the Command attribute and specifies where on the virtual machine the script is extracted. Example:
<rmsd:Location>/tmp/update</rmsd:Location>
The following additional attributes are supported for an emergency fix applied only to a virtual system:
Log
This attribute is nested inside the Command attribute and specifies the location where any log information from the script is sent. Example:
<rmsd:Log>$WAS_INSTALL_ROOT/UpdateInstaller/logs</rmsd:Log> 
Timeout
This attribute is nested inside the Command attribute and specifies that amount of time in seconds that is allowed before the script is timed out. Example:
<rmsd:Timeout>600000</rmsd:Timeout>
You can specify multiple Package sections inside a Packages section. A typical Package section for a virtual system emergency fix is similar to the following example:
<rmsd:Packages>
  <rmsd:Package name="IFPK12345" type="ifix" target="APPLICATION">
    <rmsd:EnvVariables>
      <rmsd:EnvVariable key="ENV1" defaultValue="980" type="integer">
      </rmsd:EnvVariable>
      <rmsd:EnvVariable key="ENV2" defaultValue="INV2" type="string">
      </rmsd:EnvVariable>
      <rmsd:EnvVariable key="ENV3PASSWORD" type="password">
      </rmsd:EnvVariable>
      <rmsd:EnvVariable key="ENV4" defaultValue="A" type="enum:A,B,C">
      </rmsd:EnvVariable>
      <rmsd:EnvVariable key="ENV5" defaultValue="false" type="boolean">
      </rmsd:EnvVariable>
    </rmsd:EnvVariables>
    <rmsd:Command name="/bin/sh /tmp/update/installAppService.sh">
      <rmsd:Arguments>
        <rmsd:Argument>installArg1</rmsd:Argument>
          <rmsd:Argument>installArg2</rmsd:Argument>
          <rmsd:Argument>installArg3</rmsd:Argument>
        </rmsd:Arguments>
      <rmsd:Log>$WAS_INSTALL_ROOT/UpdateInstaller/logs</rmsd:Log> 
      <rmsd:Location>/tmp/update</rmsd:Location>
      <rmsd:Timeout>600000</rmsd:Timeout>
    </rmsd:Command>
  </rmsd:Package>
</rmsd:Packages>
This example shows a similar Package section for a virtual application emergency fix, with no environment variables or command arguments defined:
<rmsd:Packages>
  <rmsd:Package name="SpecialFix" type="ifix" target="APPLICATION">
    <rmsd:Command name="/bin/sh /tmp/update/ThisIs_eFix.sh">  
      <rmsd:Location>/tmp/update</rmsd:Location>
    </rmsd:Command>
  </rmsd:Package>
</rmsd:Packages>
Examples

This service.xml example file shows an emergency fix for a virtual system.
<?xml version="1.0" encoding="UTF-8"?>
<rmsd:Service xmlns="http://www.w3.org/2001/XMLSchema" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:rmsd="http://www.ibm.com/websphere/rainmaker/service/servicedescription"
  xsi:schemaLocation="http://www.ibm.com/websphere/rainmaker/service/servicedescription ./Service.xsd">
  <rmsd:ImagePrereqs>
    <rmsd:prereq name="WebSphere Application Server 7.0.0.3" version="7.0.0.3"/>
  </rmsd:ImagePrereqs>
  <rmsd:Packages>
    <rmsd:Package name="IFPK12345" type="ifix"  target="APPLICATION">
      <rmsd:EnvVariables>
        <rmsd:EnvVariable key="WAS_USER" defaultValue="Administrator" type="string">
        </rmsd:EnvVariable>
        <rmsd:EnvVariable key="WAS_PASSWORD" type="password">
        </rmsd:EnvVariable>
      </rmsd:EnvVariables>
      <rmsd:Command name="/bin/sh /tmp/update/installAppService.sh">
        <rmsd:Log>$WAS_INSTALL_ROOT/UpdateInstaller/logs</rmsd:Log> 
        <rmsd:Location>/tmp/update</rmsd:Location>
        <rmsd:Timeout>600000</rmsd:Timeout>
      </rmsd:Command>
    </rmsd:Package>
  </rmsd:Packages>
</rmsd:Service>
This service.xml example file shows a fix for a virtual application plug-in.
<?xml version="1.0" encoding="UTF-8" ?> 
      <rmsd:Service xmlns="http://www.w3.org/2001/XMLSchema"
                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                       xmlns:rmsd="http://www.ibm.com/websphere/rainmaker/service/servicedescription"
                       xsi:schemaLocation="http://www.ibm.com/websphere/rainmaker/service/servicedescription ./Service.xsd">
  <rmsd:PluginPrereqs>
    <rmsd:prereq pluginname="caching" pluginvrmf="2.0.0.3" /> 
  </rmsd:PluginPrereqs>

  <rmsd:Packages>

    <rmsd:Package name="SpecialFix" type="ifix" target="APPLICATION">
      <rmsd:Command name="/bin/sh /tmp/update/ThisIs_eFix.sh">  
        <rmsd:Location>/tmp/update</rmsd:Location>   
      </rmsd:Command>
    </rmsd:Package>

  </rmsd:Packages>

</rmsd:Service>
1.3. Delete emergency fixes from the catalog

You can delete an emergency fix from the catalog if the fix is no longer needed or it becomes obsolete.
To complete this task, you must either have the Create new catalog content permission and have all access to the emergency fix, or have the Workload resources administration with full permissions.
When you upgrade the instances to a new version, many of the existing emergency fixes might become obsolete. Emergency fixes can also become obsolete when they are superseded by newer fixes.

Click Catalog > Emergency Fixes.

Select the fix and click the Delete icon on the toolbar.
Click OK.

1.4. Fields on the Emergency Fixes pane

You can manage the emergency fixes in the catalog using the fields on the Emergency Fixes pane in the console.

To work with emergency fixes in the user interface, click...
Catalog | Emergency Fixes

The left pane

The left pane of the Emergency Fixes pane provides the following options to work with emergency fixes:

New

Define an emergency fix. Clicking New opens a pane in which you can define the new emergency fix.

Search

Enter the name of an emergency fix in this field to search for it. You can use the up and down arrow keys to sort through the listing of emergency fixes.

Sort

Click to sort the list of emergency fixes. You can sort by the following attributes:

Sort by name
Sort by status
Sort by created time
Sort by type

List of emergency fixes

The listing of emergency fixes contains the default emergency fixes that are already defined to PureApplication System, by name.

To work with an emergency fix, first select it from the list in the left pane of the Emergency Fixes pane.

Icons on the upper right

The upper right of the Emergency Fixes pane provides the following icons:

Refresh

Refreshes the status of the emergency fixes and updates the fields on the Emergency Fixes pane.

Clone

Creates a copy of the emergency fix, even a locked emergency fix, that can be edited.

Lock

Makes the emergency fix read-only and locks it against further editing.

Delete

Removes the emergency fix from the PureApplication system catalog.

The right pane

Selecting an emergency fix shows the name of the emergency fix at the top of the right pane and the following fields on the right pane:

Description

The description of the emergency fix. You can edit this description to provide meaningful information about the emergency fix.

Type

The emergency fix can be one of the following types:

Disk
NIC
User
The type of emergency fix is selected when the emergency fix is created and this field cannot be changed after creation of the emergency fix.

Created on

The creation time of the emergency fix, as the number of seconds since midnight January 1, 1970 UTC. When the emergency fix is displayed, this value is shown as the date and time in the local timezone.

Current status

The status of the emergency fix can be one of the following status types:

The edit icon

The emergency fix can be edited.

Read-only

The emergency fix is locked to editing.

Updated on

Thd time the emergency fix was last updated, as number of seconds since midnight, January 1, 1970 UTC. When the emergency fix is displayed, this value is shown as the date and time in the local timezone. This field is read-only.

Emergency fix package files

If you are cloning one of the provided default emergency fixes, you can create custom emergency fixes by downloading and modifying the emergency fix package. The emergency fix package is defined for each type of emergency fix:

Default add disk

Download the defaultadddisk.zip package.

Default add NIC

Download the defaultaddnic.zip package.

Default add user

Download the defaultadduser.zip package.

Default raw disk

Download the defaultaddrawdisk.zip package.

The Download link beside existing script package zip files enables these packages in the catalog to be loaded.
For new emergency fixes, you can upload a custom script package by clicking the Browse field. The Browse filed opens a system file upload pane to browse to the location of the package to load. After locating the package, clicking the Upload button loads the emergency fix package to the catalog.

Included in patterns

Patterns that this emergency fix is included in.

In cloud now

Specifies if the emergency fix is currently deployed into a cloud group.

Environment

The environment property holds the emergency fix keys and default values for the emergency fix. What this field contains depends on the type of emergency fix and the situation in which you are viewing it:

If you are creating a new emergency fix, you can define the environment variables. The Add variable field, with the name and value entry fields, is used to list the environment variables to add. The Add link adds the provided environment variable to the emergency fix.
If you are viewing an emergency fix that is read-only which has environment variables set, those environment variables are shown.
If you are working with a NIC emergency fix, there are no environment variables that can be set. A NIC emergency fix must be deployed using an environment profile.

Work directory

The directory, on the virtual machine, into which files for this emergency fix package are to be placed.

Log directory

The directory, on the virtual machine, that is to contain the log files generated by this emergency fix.

Executable

Command to be invoked for this emergency fix package. The executable can be a command already on the virtual machine, for example wsadmin, tar, ant, or another system command. You can also provide the own script to be run as part of the script package.

Arguments

The field to enter any arguments that are to be passed to the command, the command line that is passed to the executable command. This field can optionally contain environment variables and other valid command-line syntax. You can also access environment using standard techniques, for example shell, or ant.

Timeout

The maximum amount of time to wait for this emergency fix to finish running on a virtual machine. Specify the timeout as the number of milliseconds to wait, or 0 to wait indefinitely for the emergency fix to complete.

Access granted to

The access control list for this emergency fix. Users or groups who have access this emergency fix are listed in this field as links. The Add more... entry field enables the owner or anyone with proper access to the emergency fix to provide access for more users or groups of users.

Upgrade virtual systems

Updates to the operating system are managed by accessing the virtual system instance and managing the operating system as you would in a physical environment. Upgrading the level of product code (for example, IBM WebSphere Application Server) with a feature pack is also done by logging in to the virtual system instance and upgrading as you would in a physical environment, unless a virtual image exists for the feature pack. Emergency fixes are used to upgrade product code to a new service level or to resolve errors. These fixes are applied by using IBM PureApplication System W1500. Emergency fixes are uploaded to the catalog and can be applied to the virtual system instances managed by the system.
You must be granted all access to the virtual system instance or have the Workload resources administration with full permissions to complete this task. The virtual system instance must be started for service to be scheduled or applied.
Interim fixes and fix packs are applied to virtual system instances as emergency fixes. When you add an emergency fix, you define the virtual images for which the fix is applicable. The list of fixes available when you schedule a service request is created by using all the fixes applicable to the virtual image used to create the virtual system instance. If a fix is already applied to the virtual system, you can see it in the History listing and it is not included in the list of available fixes.

To select and schedule service for a virtual system instance.
Instances | Virtual Systems | virtual_system_instance | Service

If no service updates are available, a message is displayed.

Select Service now to schedule the service request to start immediately. Click Schedule service to specify when the service must be applied. The default date and time for scheduled service is immediately. Modify these fields to the date and time when the service request should be started.
To select what service must be applied with this request, click...
Select service level or fixes

Complete one of the following steps:

Select Move to service level and select an available fix pack.
Select Apply emergency fixes and select the emergency fixes you want to apply. You can select more than one emergency fix to be applied by using the same service request.

Click Product administrator user name and password and specify an authorized user name and password in the fields provided.
Click OK to complete the service request. A snapshot image of the virtual system instance is automatically taken before a service request is performed.

Virtual system instance maintenance

The operating system is administered by accessing the virtual machine while it is running and managing the OS as you would in a physical environment.
You can apply interim fixes and fix packs to the virtual system instance directly from PureApplication System. Download the fixes from IBM PureSystems Centre and then upload them to the catalog. While a virtual system instance is started, you can apply the emergency fixes to all the virtual machines in the virtual system instance directly from the console.
Before an emergency fix is applied a snapshot image of the virtual system instance is taken. A snapshot image uses hypervisor-specific technology to store an image of the virtual system instance at the current state. The maximum of one snapshot image is stored for each virtual system instance, but the snapshot can be used to restore the virtual system instance if a problem arises when the emergency fixes are applied or when some other maintenance work is performed. Any time an emergency fix is applied, the service history for the virtual system instance is updated. This keeps a record of all the fixes that have been applied to this virtual system instance, so that if you restore the virtual system instance from the snapshot image or from a backup image, then you have a clear record on the service level of the restored virtual system instance.
The virtual images included with the product can be extended to add customized virtual images to the catalog. You create a clone of an existing virtual image. When a clone of a virtual image is created, a default pattern is deployed into the cloud to create a new virtual system instance. Then, you can perform any maintenance on the OS and the virtual system instance. After all the changes and maintenance have been performed on the virtual system instance, you can save these changes by capturing the virtual image. A new virtual image based on the virtual system instance you modified is created and added to the catalog.
Custom virtual images can be used to create new virtual system instances that already contain the changes you made when you created the virtual image. You perform the changes on a single virtual system instance, and by creating this custom image you easily create additional virtual system instances without having to make the same changes. To make it easy to track what changes have been made on the new virtual system instance, the list of difference between the new virtual image and the virtual image from which it was extended, is available when viewing the details for new virtual image.

Add DB2 fix packs

To add an IBM DB2 fix pack to the system, go to...
Catalog | DB2 Fix Packs | New

...and enter enter the name and, optionally, the description, for the DB2 fix pack.

Delete DB2 fix packs

To delete an IBM DB2 fix pack from the system...
Catalog | DB2 Fix Packs | fix pack | Delete icon

Upgrade Advanced Middleware Configuration

Upgrade the existing installation of Advanced Middleware Configuration to the current version. You can upgrade by one of two methods:

Upgrade the existing deployed image using Installation Manager.
Migrate data from the existing deployed image to a new deployed image of the most recent version.

After upgrading by either method, you also update the script packages.

Download sites

Download the upgrade files from the PureSystem Centre. To update an existing deployed image, download from the PureApplication System area in the Internal Systems section. To migrate data, download and deploy a PureApplication System FP1 image as a stand-alone workload.
You can also get the files from Fix Central. Specify the PureSystems product group.

Upgrade in a deployed image of Advanced Middleware Configuration

To upgrade to the latest version of the Advanced Middleware Configuration in a deployed image IBM Installation Manager.

You need access to IBM Fix Central
Have 8 GB of free space available. You may need to remove files or relocate them.
Open an ssh or X session on the deployed image of the system you want to upgrade.
Back up the installation root directory. By default the installation root is in...
/opt/IBM/RAFServer

Back up Installation Manager metadata. By default the data is in...
/var/ibm/InstallationManager

You can upgrade the installation by using Installation Manager inside the deployed image that contains Advanced Middleware Configuration.
Download files and place them on the deployed image.

Access PureSystem Centre.
Go to...
PureApplication System | Internal Systems area

...and download...

Advanced Middleware Configuration Server Fix Pack 1

Copy the file to the deployed image.

Access the deployed image.
Start an X session on the deployed image of the system you want to upgrade. You can use other tools as well, such as vncviewer in VNC. VNC is installed in the deployed image.
Start Installation Manager.
/opt/IBM/InstallationManager/eclipse/IBMIM

Stop the Advanced Middleware Configuration server. Run the following command:
/opt/IBM/RAFServer/rc/buildforge stop

Check for any remaining Advanced Middleware Configurationprocesses and stop them...
ps -ef | grep RAFServer

Use the kill command to stop the Advanced Middleware Configuration processes.
In Installation Manager, create a new repository.

Open...
File | Preferences | Repositories | Add Repository | upgrade file

In Installation Manager, click Update.
If an older version of Installation Manager is detected on the system, then you must continue with the installation of the latest release of Installation Manager. Follow the instructions in the wizard to complete the installation of Installation Manager.
In the Update Packages wizard, select the location of the package group where the package to update is installed, and then click Next. Installation Manager searches for updates in its repositories and the predefined update sites.
If updates for a package are found, then they are displayed in the Updates list on the Update Packages page. Click Next to continue.
On the Licenses page, read the license agreements for the update. If you agree to the terms of all the license agreements, click I accept the terms of the license agreements. Click Next to continue.
The features to install are displayed. You can remove the features that you do not want to install. Click Next.
For server upgrade only...

In the Database Configuration page, set database connection parameters...

User db2inst1
Pass ADMIN1234

Click Test to test the connection, then click Next to continue.
Review the database information. Select the Upgrade Checks options as required. Click Next.
On the Summary page, review the choices before installing the updates. Click Update. The upgrade process starts.
After the update process is complete, a message that confirms the success of the process is displayed on the top of the page. Click View log file to open the log file for the current session in a new window.
To close the wizard, click Finish.

Create new libraries and other objects for integration with Rational Build Forge. Use the integrateToBF command with the createAll option. The command creates only objects that do not exist in the previous version.
./integrateToBF.sh createall

Use only the createAll option. Do not remove objects (remove options).
Respond with n when the script asks to enter interactive mode.
Would you like to enter interactive mode to select the library groups you wish to create? [y, n]
n

Update the script packages.

Upgrade Advanced Middleware Configuration by migrating data from an image of the previous version

You can upgrade the Advanced Middleware Configuration by deploying the new version and then migrating data from the old version. You need root access to the existing image and the image that contains the new version of ACM.

Download and deploy the new image from the PureSystem Centre.
As user virtuser, access the deployed image running the new version of Advanced Middleware Configuration

On the deployed image running the previous version of ACM...
cp /opt/IBM/RAFServer/amcBackupAndRestore.sh /opt/IBM/RAFServer/

Access the deployed image running the existing version of ACM and log on as root.
Back up the database and the configuration data ...:
/opt/IBM/RAFServer/amcBackupAndRestore.sh backupData

The following two files are generated:

backupFiles.tar.gz

An archive file that contains the important ACM configuration files.

DB_alias.Type.Inst_name.NODEnnnn.CATNnnnn.timestamp.Seq_num

A DB2 backup image whose name has the form shown.

Copy the two generated backup files to the deployed virtual image running the new version of ACM.

Place the configuration backup file in the home directory for the virtuser user.
Place the DB2 backup file in the home directory for the DB2 instance owner, db2inst1.

Access the deployed image running the new version of ACM and log on as root.
Restore the data ...:

/opt/IBM/RAFServer/amcBackupAndRestore.sh restoreData

The script completes the following tasks:

Stops ACM
Restores the database
Restores the configuration data
Restarts ACM

Update the script packages.

Update Advanced Middleware Configuration script packages

You download and update script packages as part of the upgrade process

You need access to IBM Fix Central.
Complete the framework server upgrade.

When you upgrade Advanced Middleware Configuration, you need to update the script packages.
Download the upgrade file and place it on the deployed image.

Access the PureSystem Centre and download the upgrade file
PureApplication System | Internal Systems | Advanced Middleware Configuration Server Fix Pack 1

Copy the file to the deployed image and unzip it. Two files are in the catalog:
rafwScriptPackage.zip
ImportScriptPackage.zip

Upload the script packages.

Log in to the System Console on the image you are upgrading and select...
Catalog | Script Packages | AMC Integration Script Package | Browse | rafwScriptPackage.zip | Open | Upload

Repeat this process for the AMC Import Script Package package. Upload the ImportScriptPackage.zip file that you downloaded.

Upgrade shared service instances

Use the workload console to upgrade shared service instances to the next version.
Import any new pattern types and images that are available with the new fix pack release. Then, any shared service instances that are upgraded or deployed will use the new pattern types and images. Also, before upgrading shared service instances, be sure to stop all activity in the workload console, including deployments, deletes, stops, and so on. If a shared service instance is deployed in multiple clouds, upgrade each shared service instance in each cloud individually.

Click...
Instances | Shared Services | service instance | Upgrade | Update

The upgrade starts, and the status of the instance changes to launching and maintaining.
Wait until the status of the instance changes to running and maintaining. At this point, the upgrade process has completed. The Commit and Revert toolbar buttons display in the upper right side of the window.
Click Commit.
Now the upgrade process is committed, and the instance of the shared service cannot roll back to the previous version, for example the previous fix pack level. The status of the service instance changes to running.
Optional: To roll the shared service instance back to the previous version, click Revert.

Upgrade the external PureApplication System Agent

If you installed an external PureApplication System Agent, and you want to upgrade the agent to the latest version, follow the instructions in this topic to upgrade it. If the PureApplication System Agent is installed outside of IBM PureApplication System, it is called an external PureApplication System Agent.
Stop the following components:

The hub Tivoli Enterprise Monitoring Server (monitoring server).
If the external PureApplication System Agent is connected to a remote monitoring server, stop the remote monitoring server.
The Tivoli Enterprise Portal Server (portal server).
If you use the desktop client of Tivoli Enterprise Portal, stop the desktop client.

Install application support on the hub monitoring server and the remote monitoring server that the external PureApplication System Agent is connected to.

Windows: installing application support on a monitoring server
UNIX or Linux: installing application support on a monitoring server

Install application support on the portal server.

Windows: installing application support on a portal server
UNIX or Linux: installing application support on a portal server

Install the latest version of the external PureApplication System Agent on the computer where the older version of the agent is installed. You do not have to remove the existing agent first.

Windows: installing a monitoring agent locally
UNIX or Linux: installing a monitoring agent locally

Install language pack on the portal server.
If you use the browser client of Tivoli Enterprise Portal, you can skip this step. If you use the desktop client, follow the instructions below to install language pack on the desktop client, depending on the operating system that hosts the desktop client:
If you use the browser client of Tivoli Enterprise Portal, you can skip this step. If you use the desktop client, follow the instructions below to install application support on the desktop client, depending on the operating system that hosts the desktop client:
Windows: installing application support on a desktop client

Linux: installing application support on a desktop client

Reconfigure the external PureApplication System Agent.
Restart all upgraded components.

Clearing resources in javaws cache

After you upgrade the IBM PureApplication System, you must clear resources in javaws cache to ensure that IBM PureApplication System Monitoring Portal can open properly.

Go to the JRE installation directory on the computer where you want to open the IBM PureApplication System Monitoring Portal and run the following command to open the Java Control Panel:
javaws -viewer

The Java Control Panel window is displayed.
On the General page, click View in the Temporary Internet Files section. The Java Cache Viewer window is displayed.
From the Show list, select Resources. Resources are listed in the table.
Select all resources listed in the table and click Remove selected resources to remove them.
Click Close to close the Java Cache Viewer window.
On the Security page of the Java Control Panel window, click Certificates. The Certificates window is displayed.
Select all certificates on the User page and click Remove to remove these certificates.
Click Close to close the Certificates window.