Upgrading DB2 for z/OS databases

For DB2 for z/OS databases, increase the buffer size for table spaces, initialize new databases, and upgrade your existing schemas and data.

Figure 1. Sample environment after existing schemas and data are updated. The source environment is not running and the databases are not in use. The databases contain updated schemas and data. The target is not running but contains a deployment environment.

Run the DBUpgrade command to modify some of your existing data for use with IBM® Business Process Manager V8.5.6.

For each deployment environment that you are creating, complete the following steps:

1. To initialize your new database components, run the create*.sql files that were generated when you ran the BPMConfig -create command.
   1. Copy the create*.sql scripts for the new database components from target_deployment_manager_profile/dbscripts/Upgrade/ to your database computer.
   2. Connect to each database and run the customized SQL files against the database. You can use the BPMConfig properties file to help you determine the databases against which to run the SQL.
      If your source environment was not configured for Business Space, configure the Business Space objects by running these SQL files against a new Business Space database (if one was created) or against another database on which you want to configure the Business Space objects. Run the files in the following order:

      1. createTablespace_BusinessSpace.sql (if it exists)
      2. createSchema_BusinessSpace.sql (if it exists)
      3. createTable_BusinessSpace.sql
      If your target environment is IBM BPM Advanced with full Process Center and Process Server functionality, complete the following tasks:

      • Configure the Process database by running these files against the new Process database. Run the files in the following order:
        1. createTable_ProcessServer.sql
        2. createProcedure_ProcessServer.sql
      • Configure the Performance Data Warehouse database by running the following file against the new Performance Data Warehouse database: createTable_PerformanceDW.sql.
      For example, you can connect to the Business Space database and run the SQL as follows:

      db2 connect to BSpace_database_name USER user_name USING password
      db2 -tvf zos_directory_path/createTablespace_BusinessSpace.sql
      db2 -tvf zos_directory_path/createSchema_BusinessSpace.sql
      db2 -tvf zos_directory_path/createTable_BusinessSpace.sql
      db2 connect reset

   3. If you created a new common database for the deployment-environment-scoped common database:
      1. Run createSchema_CommonDB.sql to create the event sequencing and failed event tables.
      2. If you have data in the event sequencing table (named PERSISTENTLOCK) in the source environment, export the data from the jdbc/WPSDB data source (JNDI) name in the source and import it into the event sequencing table (PERSISTENTLOCK) in the new deployment-environment-scoped common database component. See your database provider documentation for instructions for extracting data from a table in one database and importing it into another database.
      Remember: In IBM BPM V8.5.x, the common database is split into two pieces. One is cell-scoped and is used for the entire cell. The other, which includes event sequencing and the failed event manager, is deployment-environment-scoped, and must be configured for each deployment environment.

      You are not required to create the event sequencing and failed event tables if you are using the old common database for the deployment-environment-scoped common database.

   4. To create the messaging engine tables, complete the following steps:
      1. If you are reusing your previous messaging engine database and schema, manually drop the existing messaging engine tables.
         Tip: The messaging engine table names use the SIB prefix.
      2. Run the createSchema_Messaging.sql file to re-create the tables manually on the database where you want to configure Messaging. This file is in deployment_manager_profile/dbscripts/Upgrade/cell_name.de_name/database_type/Messaging_engine_database_name.Messaging_engine_schema_name.
2. To upgrade all existing databases, complete the following steps:
   1. Ensure that the scripts have write permissions. If the tool that you want to use to view, edit, and run the scripts requires the scripts to be in EBCDIC format, rather than ASCII format, convert the files to EBCDIC.
      Important: After you convert the files from ASCII to EBCDIC, check that no SQL statements exceed 72 characters in length, and fix if necessary. Longer lines can lead to line truncation and invalid statements when you run the scripts.
   2. Connect to the database and run the customized scripts against the database by using your preferred tool; for example, the DB2 command line processor, SPUFI, or in a batch job.
      You can also use one of these methods to run the scripts:

      • Run the SQL scripts using the upgradeSchema.sh file that was generated along with the SQL scripts.
      • Run the SQL scripts directly using an SQL session.
      To run the SQL scripts directly, run the scripts in the following sequence:

      • Run all upgradeTablespac* scripts before you run any upgradeSchema* scripts.
      • Run the upgradSchema_SchemaStatus.sql script before you run any other "upgradeSchema*" SQL scripts.

      The options are embedded in the SQL scripts. Additional options are not required.

      Note: If you had the Business Process Choreographer Reporting function configured, it was removed during runtime migration. However, the associated data was not automatically removed from the database. If you determine that you no longer need this data, run the dropSchema_Observer.sql script and then the dropTablespace_Observer.sql script using an SQL session with special configuration.
3. Copy the sample migration.properties file and rename it to target_migration.properties. Update the file with the configuration information for the target environment. Check all the target properties and edit them if required, following the instructions in the sample file. The sample file is in install_root/util/migration/resources/migration.properties.

   Ensure that all properties have been changed to the target (not source) environment. Ensure that the value of the target.config.property.file property is set to the full path of the configuration properties file that you used to create your target environment. You must also set the value of profile.name to the name of the new deployment manager profile.

4. Go to the target_install_root/util/dbUpgrade directory and set the database.is.db2zos property to true in the upgrade.properties file. For example:

   database.is.db2zos=true

5. To upgrade the databases to V8.5.6, run the DBUpgrade utility on the server in the target environment.
   Important: Ensure that your deployment manager and all the managed nodes in the source environment have been stopped before running this utility.

   install_root/bin/DBUpgrade.sh -propertiesFile target_migration_properties_file -backupFolder snapshot_folder

   where:
   • target_migration_properties_file is the full path to the migration properties file in which you specified the configuration information for the target environment.
   • snapshot_folder is the directory that contains the information that was extracted from the source environment
   For example:

   install_root/bin/DBUpgrade.sh -propertiesFile /opt/BPM85/util/migration/resources/target_migration.properties -backupFolder /tmp/snapshot

   The command displays each database upgrade action as it runs. After all the upgrades are finished, you see a message similar to the following message:

   All upgrade steps have been completed successfully.

   The log location is listed in the output. If there are errors or exceptions, they appear in the log.