IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Upgrading from IBM BPM V8.0 to IBM BPM V8.0.1 > Upgrading an ND environment
Upgrading clusters
Complete these steps to upgrade clusters in an ND environment.
After upgrading the dmgr and the managed nodes containing cluster members, follow these steps to upgrade each of the clusters in your ND environment before starting the cluster members (servers).
If minimum downtime is the objective during this upgrade, special precautions should be taken. These are documented separately in the topic "Upgrading clusters with minimum downtime."
Procedure
- Stop the dmgr, if it is running.
- On the dmgr, change directories to INSTALL_ROOT.
- Run the following command for each cluster:
![]()
- For English locales: bin\ws_ant.bat -f util\BPMProfileUpgrade.ant -profileName profile_name -Dupgrade=true –Dcluster= cluster_name
- For non-English locales: bin\ws_ant.bat -f util\BPMProfileUpgrade.ant -profileName profile_name -Dupgrade=true "–Dcluster= cluster_name"
bin/ws_ant.sh -f util/BPMProfileUpgrade.ant -profileName profile_name -Dupgrade=true –Dcluster= cluster_name
where profile_name is the name of the dmgr profile and cluster_name is the name of the cluster.
- Check the following log file for errors: profile_root/logs/BPMProfileUpgrade. profile_name. cluster_name. timestamp.log where profile_root is the root directory of the dmgr profile. If there is an error, fix the cause, then rerun Step 3.
- Before you update the databases, ensure that you have applied Mandatory Interim Fix JR44669. See
Required interim fix for APAR JR44669. To download the fix, see
Required interim fixes for IBM BPM.
- Update the Process Server database for each cluster where the Business Process Definition engine is configured.
- For all database types except DB2 on z/OS on the installation that hosts the dmgr:
BPM\Lombardi\tools\upgrade\UpgradeProcessData\upgradeProcessData.bat -profileName profile_name -nodeName node_name -serverName server_name
BPM/Lombardi/tools/upgrade/UpgradeProcessData/upgradeProcessData.sh -profileName profile_name -nodeName node_name -serverName server_name
where profile_name is the name of the dmgr profile, node_name is the name of any cluster node, and server_name is the name of any member of the cluster on that node. For more information about the parameters that you can use with the upgradeProcessData command, see upgradeProcessData command-line utility.
- If you are using DB2 on z/OS, you must manually alter a set of table spaces and upgrade the database schema before you upgrade the database data:
- To ensure that you can successfully run the SQL files for the DB2 for z/OS schema upgrade, alter the following table spaces to increase the buffer pool size to 8K:
- WLPT36
- WLPT44
- WLPT64
For information about altering table spaces, see
DB2 for z/OS - Technical Resources
Altering table spaces (DB2 for z/OS V9) in the DB2 Information Center
Altering table spaces (DB2 for z/OS V10) in the DB2 Information Center
- From the INSTALL_ROOT/profiles/ profile_name/dbscripts/ProcessServer/DB2zOS/ database_name directory, copy the script named upgradeSchema800_ProcessServer.sql to your working directory.
Review the script, and, if necessary, edit the file to replace the following symbolic variables with the actual values for the schema name, database name, storage group, and buffer pool for large objects and tables: @SCHEMA@, @DB_NAME@, @STOGRP@, @BPLOB4K@, @BPTABLE4K@, and @BPTABLE8K@. Then connect to the DB2 for z/OS database, and run the script against the database by using your preferred tool.
- From the INSTALL_ROOT/profiles/ profile_name/dbscripts/PerformanceDW/DB2zOS/ database_name directory, copy the script named upgradeSchema800_PerformanceDW.sql to your working directory.
Review the script, and, if necessary, edit the file to replace the following symbolic variables with the actual values for the schema name, database name, storage group, and buffer pool for large objects and tables: @SCHEMA@, @DB_NAME@, @STOGRP@, @BPLOB4K@, @BPTABLE4K@, and @BPTABLE8K@. Then connect to the DB2 for z/OS database, and run the script against the database by using your preferred tool.
- Go to the [IBM_BPM_home]/BPM/Lombardi/tools/upgrade/UpgradeProcessData directory and set the database.is.db2zos property to true in the upgrade.properties file.
For example:
database.is.db2zos=true- Run the following command on the installation that hosts the dmgr:
BPM\Lombardi\tools\upgrade\UpgradeProcessData\upgradeProcessData.bat -profileName profile_name -nodeName node_name -serverName server_name
BPM/Lombardi/tools/upgrade/UpgradeProcessData/upgradeProcessData.sh -profileName profile_name -nodeName node_name -serverName server_name
where profile_name is the name of the dmgr profile, node_name is the name of any cluster node, and server_name is the name of any member of the cluster on that node. For more information about the parameters that you can use with the upgradeProcessData command, see upgradeProcessData command-line utility.
If you are using IBM BPM for z/OS and have set up symbolic links, additionally specify the -wasHome WAS_HOME parameter when you run the upgradeProcessData command.
The upgrade_7x command obtains the database information from the <profile-root>/db/*/bpm.standard.nd.dbDesign file and updates only the database and not the configuration files. The concrete name of the .dbDesign file will be printed by the upgrade_7x command when it executes, for example:
IBM BPM 7.5.1 Upgrade Loading environment settings Reading Database information from C:\IBM\BPMV\profiles\Dmgr01\properties\db\BPM.AppTarget\bpm.standard.nd.dbDesignIf Performance Data Warehouse is configured on a different cluster, for example, when using one of the "Remote Support" topology patterns, you must also supply the -perfNodeName <pdw_node_name> and -perfServerName <pdw_server-name> parameters, where <pdw_node_name> is the name of any Performance Data Warehouse cluster node, and <pdw_server-name> is the name of any member of the Performance Data Warehouse cluster on that node.
For example:
upgrade_7x.sh -profileName MyDMgr1 -nodeName TestNode1 -serverName TestEnv.AppTarget.0 -perfNodeName TestNode1 -perfServerName TestEnv.Support.testNode14.0If you have configured Business Process Choreographer, you must upgrade the BPEDB database manually to create the SCHEMA_STATUS table.
- Change to the directory where the Business Process Choreographer database scripts are generated. Run the following command on the installation that hosts the dmgr:
cd profile_root\dbscripts\ProcessChoreographer\ db_type\ db_name\ schema_name
cd profile_root/dbscripts/ProcessChoreographer/ db_type/ db_name/ schema_name
where profile_root is the root directory of the dmgr profile, db_type is the database type, db_name is the database name, and schema_name is the (possibly empty) schema name.
- If the database server is remote and you do not have a local database client, copy the upgradeSchema_SchemaStatus.sql script to the database server so that you can run it there.
- Run the upgradeSchema_SchemaStatus.sql script to create the SCHEMA_STATUS table in the Business Process Choreographer database. If the table already exists, there will be an error that you can ignore.
- When all clusters have been successfully upgraded, restart the dmgr.
For each node in the cluster, manually update the profile as follows:
- From the INSTALL_ROOT directory, run the following command:
bin/ws_ant.sh -f util/BPMProfileUpgrade.ant -profileName profile_name -Dupgrade=true -Duser= userID -Dpassword= password
where profile_name is the name of the profile (which on z/OS is default), userID is a user ID that has administration authority, and password is the password for that user ID.
- Check for any errors as explained in the "Identifying profile update errors" section of Recovering from profile update errors before continuing.
- For each node, restart the node agent, and wait for the node synchronization to complete.
- If you have disabled automatic synchronization, ensure that all of your nodes are correctly synchronized before starting the cluster members.
- Start all the servers and cluster members, as needed.
Upgrading clusters with minimum downtime
Special precautions are required if minimum downtime is required during an upgrade in an ND environment.
Related concepts:
Topologies of a ND environment
Related tasks:
Upgrading clusters with minimum downtime
Executing SQL upgrade scripts
Related reference:
Recovering from profile update errors