Installing and configuring the 6.1.2 business process management stack on z/OS

This article guides you through several processes, including configuring the products that make up the business process management stack on the z/OS® operating system, as well as backing up and recovering the file systems that make up the cell and database. Throughout the article we provide pointers to the existing documentation as well as any detailed instructions for any task we completed that we did not find in existing documentation. This article is intended for System z systems programmers responsible for IBM® WebSphere® and IBM Information Management software.

Timothy C. Fanelli (tfanelli@us.ibm.com), WebSphere Family Persona for z/OS, IBM

Photo of Timothy FanelliTimothy C. Fanelli is a software engineer for IBM Poughkeepsie working from Clarkson University, in Potsdam, New York.



H. Michael Everett (meveret@us.ibm.com), WebSphere Family Persona for zOS , IBM

Photo of Michael EverettH. Michael Everett is a software engineer for IBM Poughkeepsie working from Indiana University of Pennsylvania, Pennsylvania.



18 January 2010

Also available in Chinese Russian

Introduction

The first section of this article describes creating a cell. We then cover configuring these products that make up the business process management stack:

  • IBM WebSphere Application Server Network Deployment Version 6.1.0.27
  • IBM WebSphere Process Server V6.1.2.2
  • IBM WebSphere Business Services Fabric Version 6.1.2.2
  • IBM WebSphere Service Registry and Repository Version 6.1.2.2

The final section describes backing up the existing cell.

You should have a good understanding of zSeries operations, including the execution of Job Control Language® jobs, execution of shell scripts within the UNIX shell environment, and the commands associated with configuration changes within DB2 for z/OS®. This article does not cover why you would want to invest in these tools, for more information, see the Business Process Management site.

We also do not cover installing the product binaries in this article. We assume that the products discussed are located on the target machines.


Creating the cell

For a complete picture of the tasks involved in creating a business process management cell, in this section we describe the high-level tasks for creating the cell from scratch.

Reference:Application Server for z/OS Information Center

For the WebSphere Network Deployment cell we didn’t deviate from the typical Version 6.1 installation and customization. No special consideration was needed with respect to the rest of the business process management stack at the 6.1 level.

For creating a WebSphere Process Server environment, the initial WebSphere Application Server consists of a deployment manager node, and one or more empty, unfederated, managed nodes.

Creating the deployment manager node

Important: Your deployment manager must have been created using the Deployment Manager template, and it must not contain any federated nodes.

Begin by creating a new WebSphere Application Server 6.1 Network Deployment Cell, by following the instructions in the information center's Creating a network deployment cell.

When you are finished with this step, you should have a new cell with a deployment manager, and no nodes.

Create the empty managed node

Important: Do not federate the empty managed node until Process Server configuration is completed.

Create a new managed node which will be federated into your network deployment cell, by following the instructions in the information center's Creating a managed node.


Business process management configuration overview

So far you have created the starting point for the business process management cell , as shown in Figure 1:

Figure 1. The deployment manager and an unfederated empty managed node
Diagram showing a z/OS partitiion with a Network Deployment Cell containing a Deployment Manager node, which intersects with a non-federated empty managed node

The following sections guide you through installing and configuring WebSphere Process Server, WebSphere Business Services Fabric, and WebSphere Services Registry and Repository to complete your business process management installation.


Installing WebSphere Process Server

System programmer's note: We ended up with quite a few file systems containing the product code for this task. By completion we had:

  1. Application Server Version 6.1.0.27 product code zFS
  2. Process Server Version 6.1.2 product code zFS
  3. Business Services Fabric Version 6.1.2 product code zFS
  4. Service Registry and Repository Version 6.1.2 product code zFS
  5. Process Server Version 6.2 product code zFS
  6. Business Services Fabric Version 6.2 product code zFS
  7. Service Registry and Repository Version 6.2 product code zFS
  8. Deployment Manager Node Configuration zFS
  9. Node with Cluster Containing Business Services Fabric Configuration zFS
  10. Node with Cluster Containing Service Registry and Repository Configuration zFS

You can use either zFS or HFS file systems; we choose zFS for better performance.

In this section, you see how to configure the initial WebSphere Application Server environment, prepared earlier, and install the business process management stack products into it.

The high level process overview is as follows:

  1. Gather required DB2 information for creating BPM supporting databases.
  2. Install Process Server into the cell's deployment manager
  3. Create the Process Server Common Database
  4. Install Process Server into the managed node
  5. Federate the empty node into the deployment manager cell.
  6. Create a process server cluster.
  7. Create the messaging engine data sources.
  8. Configure SCA.
  9. Configure Business Process Choreographer.
  10. Configure Common Event Infrastructure.
  11. Install Business Services Fabric application into the cell
  12. Install the Services Registry and Repository application into the cell.

Configuring the DB2 environment

Database prerequisites

Important: This section is not documented in any Information Center; this information is for your DB2 systems programmer.

In this section, we gather information required to create the databases that support WebSphere Process Server. The WebSphere Process Server installation process generates several SQL scripts. You will use these scripts as templates to create the necessary databases for a Process Server cell. Prior to running any of the generated SQL, you must complete the following prerequisites:

  1. Set up new buffer pools to use for the Process Server databases and tablespaces.
  2. Determine the proper storage group.
  3. Determine the appropriate segment size for tablespaces.
  4. Determine the primary storage size.
  5. Customize the generated SQL scripts.

In our DB2 system, we created the new buffer pools shown in Table 1.

Table 1. General printer configuration changes
Buffer Pool NameSizeDescription

BP1

20K Pages

Used to store user data.

BP17

20K Pages

Used for indexes.

BP16K0

10K Pages

Used for LOB objects.

Listing 1. The display command for the buffer pools on our test system
-D4P1 DIS BUFFERPOOL(BP1)                                              
DSNB401I  -D4P1 BUFFERPOOL NAME BP1, BUFFERPOOL ID 1, USE COUNT 24
DSNB402I  -D4P1 BUFFER POOL SIZE = 20000 BUFFERS
ALLOCATED       =    20000   TO BE DELETED   =        0
IN-USE/UPDATED  =        0   BUFFERS ACTIVE  =      316
DSNB406I  -D4P1 PGFIX ATTRIBUTE -
CURRENT = NO
PENDING = NO
PAGE STEALING METHOD = LRU
DSNB404I  -D4P1 THRESHOLDS -
VP SEQUENTIAL    = 80
DEFERRED WRITE   = 50   VERTICAL DEFERRED WRT  = 10,  0
PARALLEL SEQUENTIAL =50   ASSISTING PARALLEL SEQT=  0
DSN9022I  -D4P1 DSNB1CMD '-DIS BUFFERPOOL' NORMAL COMPLETION

-D4P1 DIS BUFFERPOOL(BP17)                                               
DSNB401I  -D4P1 BUFFERPOOL NAME BP17, BUFFERPOOL ID 17, USE COUNT 25
DSNB402I  -D4P1 BUFFER POOL SIZE = 20000 BUFFERS
ALLOCATED       =    20000   TO BE DELETED   =        0
IN-USE/UPDATED  =        0   BUFFERS ACTIVE  =      708
DSNB406I  -D4P1 PGFIX ATTRIBUTE -
CURRENT = NO
PENDING = NO
PAGE STEALING METHOD = LRU
DSNB404I  -D4P1 THRESHOLDS -
VP SEQUENTIAL    = 80
DEFERRED WRITE   = 50   VERTICAL DEFERRED WRT  = 10,  0
PARALLEL SEQUENTIAL =50   ASSISTING PARALLEL SEQT=  0
DSN9022I  -D4P1 DSNB1CMD '-DIS BUFFERPOOL' NORMAL COMPLETION

-D4P1 DIS BUFFERPOOL(BP16K0)                                             
DSNB401I  -D4P1 BUFFERPOOL NAME BP16K0, BUFFERPOOL ID 120, USE COUNT 2
DSNB402I  -D4P1 BUFFER POOL SIZE = 10000 BUFFERS
ALLOCATED       =    10000   TO BE DELETED   =        0
IN-USE/UPDATED  =        0   BUFFERS ACTIVE  =       32
DSNB406I  -D4P1 PGFIX ATTRIBUTE -
CURRENT = NO
PENDING = NO
PAGE STEALING METHOD = LRU
DSNB404I  -D4P1 THRESHOLDS -
VP SEQUENTIAL    = 80
DEFERRED WRITE   = 50   VERTICAL DEFERRED WRT  = 10,  0
PARALLEL SEQUENTIAL =50   ASSISTING PARALLEL SEQT=  0
DSN9022I  -D4P1 DSNB1CMD '-DIS BUFFERPOOL' NORMAL COMPLETION

For the database, we used storage group WP1GSG, a segment size of 32K, and a primary storage size of 1 cylinder. Contact your DB2 system programmer to find or create an appropriate storage group.

Customizing the generated SQL scripts

Important: This section is not documented in any Information Center; the SQL scripts need to be reviewed by your DB2 administrator.

You will use the information gathered here to modify the SQL scripts, which will be generated later. Look for CREATE DATABASE, CREATE TABLESPACE, and CREATE LOB TABLESPACE statements, and alter them to use the appropriate buffer pools and storage groups.

For example, the CREATE DATABASE statement shown here would create a new database, WT9DB1, that uses: BP1 buffer pool for user data, BP16K0 buffer pool for indexes WP1GSG storage group. Similarly, when creating tablespaces and LOB tablespaces, you specify the segment size, buffer pool, and storage group.

Listing 2. Example CREATE statements using customized parameters
CREATE DATABASE WT9DB1 BUFFERPOOL BP1 INDEXBP BP17 STOGROUP WP1GSG;

CREATE TABLESPACE WT9TS1 BUFFERPOOL BP1 SEGSIZE 32 
IN WT9DB1 USING STOGROUP WP1GSG PRIQTY 720;

CREATE LOB TABLESPACE WT9LOBTS1 BUFFERPOOL BP16K0 SEGSIZE 32
IN WT9DB1 USING STOGROUP WP1GSG PRIQTY 720;

Running the generated SQL scripts

Once you have edited the database creation scripts, the procedures to execute them are detailed in the following sections of the Information Center:

Installing Process Server into the deployment manager

The process is broken down into several steps:

  1. Install the Process Server code into the deployment manager.
  2. Augment the deployment manager profile.
  3. Create the common database objects.

Prerequisites

This section assumes that you have already created an Application Server Deployment Manager profile. Your deployment manager must have been created using the “Deployment Manager” template, and it must not contain any federated nodes.

For the installation of Process Server into the cell, our product binaries are located in OMVSWS.WPS6122.ZFS and mounted at /wt961/D008206.

Our sample cell deployment manager is installed to /wt961/dmnode.

Installing Process Server 6.1.2 into the File System

This step of the installation process creates the necessary symbolic links to the Process Server node, and also copies required files such as profile templates and other necessary items into the cell's deployment manager installation directory.

Connect to the host system's UNIX Systems Services. Change directories to the equivalent of our Process Server product code directory: /wps61/D008206/zWPS/V6R1M2/zos.config/bin.

From this bin directory, execute the installation script to install the Process Server code into the deployment manager node, changing the syntax to match your own paths.

./zSMPInstall.sh -smproot /wps61/D008206/zWPS/V6R1M2 
–runtime /wt961/dmnode/DeploymentManager -install

When installation completes, inspect the console output for messages. You should see several informational messages, and no errors. This script has updated your deployment manager node with Process Server code. You can observe the following changes:

  • Creation of several new templates under your deployment manager’s profileTemplates directory.
  • Creation of ProcessChoreographer and BusinessSpace directories under the deployment manager.
  • Addition of several new shell scripts (zWPS*) in the deployment manager's bin directory.

Augmenting the deployment manager profile

This step augments your deployment manager's profile with the Process Server profile templates. An output of this process is a set of SQL scripts, which you need to execute later to create the Process Server database, which is necessary prior to starting the deployment manager or configuring the application nodes with Process Server. As such, some advanced planning is recommended (and required) before running the Process Server configuration scripts.

Configuring the response file

The Process Server configuration script is effectively a wrapper around WebSphere’s manageprofiles script. Its functionality is driven by a response file, which you must create. You can locate a sample script at your equivalent path at:

/wps61/zWPS/V6R1M2/zos.config/samples/DmgrDB2.rsp

Since you will need to modify this file, copy it to your current working directory.

If you specify a new user ID and password, be sure they are defined in the security product prior to creating the database in the next section. Since a database connection is not made until you try to start the deployment manager, you may continue with the configuration before this is done.

Open your working copy of DmgrDB2.rsp in a text editor and inspect the properties you will need to set. In particular, consult with your database administrator to determine the database location, name, user, password, etc. The sample response file is quite large and very well commented. It is important to read through it thoroughly and carefully. You will use many of the Global Properties to define administrative objects in your deployment manager, such as Java Database Connectivity (JDBC) data sources, messaging engines, etc.. If you make a mistake in your properties, it will be time consuming and tedious to correct the error later.

Augmenting the profile

Change directories to your deployment manager node's bin directory:

/wt961/dmnode/DeploymentManager/bin

From this directory, execute the following command:

./zWPSConfig.sh -augment -response /path/to/copy/DmgrDB2.rsp

As was the case with the installation script, output is logged directly to the console. The zWPSConfig.sh script performs the following tasks:

  1. Augments the deployment manager profile indicated in the response file with the following profile templates:
    • dmgr.wbicore
    • dmgr.bfm
    • dmgr.wbiserver
  2. Indicates the augmented profile with properties profileName and profilePath in the response file
  3. Generates a set of SQL scripts in the deployment manager's dbscripts directory.
    /wt961/dmnode/DeploymentManager/dbscripts/DBNAME/DBPRODUCT
    DBPRODUCT and DBNAME are properties from the response file.

The configuration task takes approximately 10 minutes to complete. When it is finished, investigate the console output for messages. You should see several information messages and an indication the processing completed successfully. Additionally, the configuration script uses WebSphere Application Server's manageprofiles script, additional logged information may be found in your deployment manager’s log directory under managedProfiles.

Creating the databases

The final step in configuring the Process Server deployment manager is to create the Process Server common database. You will create several other databases later. For now, however, only the common database is necessary.

Using the Process Server common database scripts

The first database contains the tables necessary to support a Process Server augmented deployment manager profile. Several database scripts were generated when you augmented the deployment manager. They are stored in the dbscripts directory under your deployment manager's installation directory.

/wt961/dmnode/DeploymentManager/dbscripts/CommonDB/DB2zOSV8

Copy the scripts to a local working directory, so that you can make changes to them as necessary. Table 2 lists the scripts you will need to create the tables, tablespaces, and other database artifacts for the Process Server common database. You must manually edit any scripts that indicate the creation of one or more tablespaces, as described above in the Database prerequisites for Process Server section.

Table 2. The scripts to create the databases
Script NameNotes

createTable_AppScheduler.sql

Creates two tablespaces and one LOB tablespace

createTable_CommonDB.sql

Creates one tablespace

createTable_customization.sql

Creates two tablespaces and two LOB tablespaces

createTable_EsbLoggerMediation.sql

Creates one tablespace and one LOB tablespace

createTable_lockmanager.sql

Creates on tablespace

createTable_Recovery.sql

Creates two tablespaces and four LOB tablespaces

createTable_Relationship.sql

Creates one tablespace

createTable_RelationshipMetadataTable.sql

insertTable_CommonDB.sql

Setting up the Process Server common database

The response file used to augment deployment manager's profile contains a property called SQLDB. The value of this property is the name of the Process Server Common Database, and is used throughout the scripts. You must manually create this database, by executing the following statement:

CREATE DATABASE <DBNAME> BUFFERPOOL BP1 INDEXBP BP17 STOGROUP WP1GSG;

where <DBNAME> is the value of the SQLDB parameter from your DmgrDB2.rsp file. After you have created the database, execute each of the scripts from the table in the previous section. Be sure you have made the necessary changes to the tablespaces, storage groups, and buffer pools as described in the Database prerequisites section of this document. The order they are listed is the order in which they were executed.

Installing Process Server into an empty managed node

This section describes the installation of Process Server 6.1.2 into an empty, un-federated managed node. The process if very similar to the installation in the deployment manager:

  1. Install the Process Server code into the node
  2. Augment the node profiles
  3. Federate the node into the cell

This section assumes that:

  • You have already installed Process Server into a Deployment Manager node.
  • You have created an empty, managed node profile to install Process Server.
  • For the installation of Process Server into the cell, you have installed the managed node WT9JC0 at /wt961/wt9jc0.

Installing Process Server into the cell

Just as you did in installing Process Server into the deployment manager, connect to the host system’s UNIX Systems Services environment as your managed node’s administrative user ID. Change the directory to your equivalent to zWPS/V6R1M2/zos.config/bin under Process Server’s product file system.

/wps61/D008206/zWPS/V6R1M2/zos.config/bin

Execute the installation script to install the Process Server code into the managed node's configuration file system.

./zSMPInstall.sh -smproot /wps61/D008206/zWPS/V6R1M2 
-runtime/wt961/wt9jc0/AppServer -install

Again, watch the console output for errors and/or warnings. Observable changes to the node's filesystem include:

  • Creation of several new templates under your deployment manager’s profileTemplates directory
  • Creation of ProcessChoreographer and BusinessSpace directories under the deployment manager
  • Addition of several new shell scripts (zWPS*) in the deployment manager's bin directory.

Augmenting the node's default profile

This step augments the managed node's default profile with the Process Server profiles. It is very similar to augmenting the deployment manager node's default profile.

  1. Configuring the response file: You can locate a sample script at: /wps61/zWPS/V6R1M2/zos.config/samples/ManagedDB2.rsp.
  2. Augmenting the profile: Change directories to your managed node's bin directory: /wt961/wt9jc0/AppServer/bin. From this directory, execute the following command:
    ./zWPSConfig.sh -augment -response /path/to/copy/ManagedDB2.rsp

    The configuration task takes approximately 10 minutes to complete. When it is finished, investigate the console output for messages. You should see informational messages and an indication that the processing completed successfully. Additionally, since the configuration script uses WebSphere Application Server's manageprofiles script, you can find additional logged information in your managed node's log directory, under manageprofiles.

Setting file system permissions

These steps installed the Process Server application into our WebSphere environment’s file systems, and augmented profiles with the new process server code. At this point we recommend you run the BBOMHFSB customization job for your deployment manager and managed nodes again. This job sets the file system’s permissions and owner/group attributes to their correct values.

Federating the Process Server managed node into the Network Deployment cell

At this point, you can federate the node using the generated customization jobs. After you have successfully federated the node, you can begin enabling the individual Process Server components for use.

This section provides the high level steps for federating an empty managed node into a deployment manager cell. These steps are taken from WebSphere Information Center: Federating a stand-alone application server into a Network Deployment cell.

  1. Log on to the z/OS system on which you intend to federate the server.
  2. Start the Customization Dialog.
  3. Choose the configuration data sets in which you will store your customization jobs and data.
  4. Load the common MVS groups and users variables.
  5. Set the customization variables according to the values recorded on your federated application server node worksheet. See Setting the customization variables: Federated application server nodefor instructions:
  6. Create the customization jobs and files, based on the customization variable values you entered.
  7. Follow the generated customization instructions.

Our configuration now includes the profiles for Process Server and the common database. The current business process management cell is depicted in Figure 2:

Figure 2. The deployment manager and federated node augmented for Process Server
Diagram showing z/OS partition showing a Network Deployment Cell containing Deploment Manager Node augmented for Process Server and Empty Managed Node augmented for Process Server, with an ajacent CommonDB

Creating a new Process Server Cluster

Process Server consists of three primary components:

  • Common Event Infrastructure
  • Services Component Architecture
  • Business Process Management

This section steps you through enabling and configuring each of these components on a new Process Server cluster.

Component databases

Each of the three components requires that you create one or more databases to to support it. In all cases, refer to the information provided in the section Database prerequisites for Process Server. You need to make manual changes to the provided SQL scripts before executing them.

Golden topology

Due to architectural differences between WebSphere Application Server on z/OS and WebSphere Application Server on other platforms, the golden topology on zOS is a single-cluster setup. For a detailed explanation, see the document titled Expanding clustered topologies for Process Server and Enterprise Service Bus.

Create a new cluster

The first step is to create a new process server cluster. This process is identical to creating a WebSphere Application Server cluster. You must use the defaultProcessServerZOS template when you create the servers in the cluster, and configure without any special consideration for creating a new application server cluster on z/OS.

Create a message engine database

Each of the Process Server components relies on one or more service integration buses, which are backed by a messaging engine database. Use the sibDDLGenerator.sh to generate the DDL for these databases, as shown here:

AppServer/profiles/default/bin/sibDDLGenerator.sh -system db2         \
   -version 8.1 -platform zos -schema WPSDBSCH -user WPSDBADM         \
   -create -database WPSDBWT9 -storagegroup WP1GSTG -statementend ";" \
   > /u/wt9adm/WT9CFG/SIBSCA.ddlConfiguring the SCA Component

Customize the DDL to use the storage groups and buffer pools you identified in the Database prerequisites section of this document.


Configure SCA support

The SCA component requires two message engine databases, one to support the system bus member, and one to support the application bus member. Use the script described above to generate the DDLs, and create the two message engine databases.

  1. Configure the SCA component using the Process Server administrative console. Log into the administrative console, and browse to: Servers > Clusters > Cluster Name > Business Integration > Service Component Architecture.
  2. Check the box titled Support the Service Component Architecture components.
  3. Verify and update the settings in the System Bus Member box.
  4. Verify and update the settings in the Application Bus Member box.
  5. Click OK to continue. The administrative console will configure and enable SCA on your cluster. When it is complete, save your changes to the master configuration, and synchronize the node(s).
  6. Restart the cluster.

Verifying the SCA component

If the settings specified in the SCA configuration page were not correct, then errors will be recorded in the cluster member's adjunct region during and after server start up. If the message engines are unable to connect to the data store tables, you will see recurring messages in the adjunct region indicating that the message engine is lost or was unable to acquire an initial lock on the data store.

Additionally, you may query the schema name.SIBOWNER tables for information. Each SIBOWNER table should have exactly one record. If there are zero records in this table, then no message engine was able to connect to it. If there is one record in this table, then a message engine has successfully connected to it.


Configure Business Process Choreographer

On z/OS, you can use the sibDDLGenerator script in was_installation_root/bin to create the SQL scripts for the messaging engines database. Use the sibDDLGenerator script to create SQL scripts for use in a production environment.

Generate the BPC databases

The BPC configuration creates a single message engine, which requires a message engine data store, similar to the SCA component. Create a message engine database as described above.

The BPC component also requires the process choreographer database. See Creating a DB2 for z/OS database for Business Process Choreographer .

Be sure to use the same schema when you create the message engine as you do when you create the BPC tables, since Business Process Choreographer requires a single database, in our case WT9BPCDB, with a single schema.

Configure the Business Process Choreographer component

After you have generated the message engine data store tables, you can configure the Business Process Choreographer component using the Process Server administrative console.

  1. Log into the administrative console, and browse to: Servers > Clusters > Cluster Name > Container Settings > Business Process Choreographer Container Settings > Business Process Choreographer Containers
  2. Check the box titled Support the Service Component Architecture components.
  3. Verify and update the settings in the System Bus Member box .
  4. Verify and update the settings in the Application Bus Member box .
  5. Enable and install BPC Explorer by selecting: Servers > Clusters > Cluster Name > Container Settings > Business Process Choreographer Container Settings > Business Process Choreographer Explorer.
  6. Add the cluster to target table.

Validating the Business Process Choreographer installation

Process Server provides an initial verification test, located in installableApps/bpcivt.ear Install this application choosing all default values during the installation process Browse to http://server:port/bpcivt. The automated test should result in a Passed message or provide exception details.


Configuring the Common Event Infrastructure

In this section we generate the Common Event Infrastructure (CEI) databases, and configure the CEI component

Generating the CEI databases

Follow the instructions in this infocenter document:Populating the Event Databases. It will guide you through creating and populating the CEI tables.

Additionally, CEI requires a message engine database, which you can create using the directions above. On z/OS, you can use the sibDDLGenerator script in was_installation_root/bin to create the SQL scripts for the messaging engines database. Use the sibDDLGenerator script to create SQL scripts for use in a production environment.

Configuring the CEI component

  1. Log in to the Administrative Console, and browse to Servers > Clusters > Cluster Name > Business Integration > Commen Event Infrastructure > Common Event Infrastructure Server.
  2. Enable the common event infrastructure server.
  3. Complete the two tables, and click OK.

Adding Business Services Fabric to the cell

The installation of Business Services Fabric was straightforward. We did nothing that was not in the Information Center: Manual installation process.

For Business Services Fabric the steps are as follows:

  1. Create the databases.
  2. Run a series of JACL scripts.
  3. Create JDBC resources.
  4. Create JMS resources.
  5. Create J2C authorization aliases.
  6. Install the applications.

Adding Service Registry and Repository to the Cell

Activation of Service Registry and Repository consists of the following steps:

  1. Copy the installed binary directory to the working deployment directory.
  2. Create the databases
  3. Run a script to copy the DB2 SQL and Job Control Language to datasets.
  4. Deploy Service Registry and Repository for z/OS
  5. Run the deployment script and verify the installation.

See Activating WSRR for z/OS for the documented steps for these stages. Our product code is located at this path: /wsrr61/ga/V6R1M0.

Service Registry and Repository installation steps

To create the deployment directory, copy the installation files to a working directory:

cp -R /wsrr61/ga/V6R1M0 wsrrinstall

To create the database, you first need to create the databases scripts:

cd wsrrinstall/install/database/sql/db2_ZOS
./copyddl.sh -sqldsn FANELLI.WSRRINST.SQL -jcldsn FANELLI.WSRRINST.JCL

These steps should create the database scripts and jobs in FANELLI.WSRRINST, as Figure 3 shows:

Figure 3. Generated database definition scripts
Command prompt window showing output of above commands

FTP to the host and copy each of the members in FANELLI.WSRRINST.SQL to your local workstation, which lets you edit the files and execute them using standard DB2 utilities, rather than via SPUFI or the JCL scripts created for you.

You need to replace the five tokens used in the database definitions with values like ours (Table 3), but matching what your database administrator provided:

Table 3. Substitutions necessary in the WSRR SQL scripts
TokenValue used

<SCHEDULER-DATABASE>

WT9SCHDB

<SCHEDULER-LOB-TABLESPACE>

WT9SCHLT

<SCHEDULER-TABLESPACE>

WT9SCHTS

<SIB-DATABASE>

WT9SRSIB

<XMETA-DATABASE>

WT9SRXDB

You also need to make changes to the account for schema names, storage groups, buffer pools, etc.

Deploying the Service Registry and Repository for z/OS

To deploy the Services Registery and Repository for z/OS, run the commands in Listing 3.

Listing 3. Commands for deploying the Service Registery and Repository
cd wsrrinstall/install/

./installall.sh -db-password WPSDBADM -was-password witpw -was-user WT9ADM 
-administrator-user WT9ADM -user-user WT9ADM 
-was-home /wt961/dmnode/DeploymentManager -was-profile default -soap-port 25002 
-db-home /db2810/currentwp1g/ -db-type db2v8 -db-name USIBMDB2WP1G 
-db-user WPSDBADM -db-schema WPSDBADM -db-port 51100 
-db-hostname jc0eip.pdl.pok.ibm.com -configdb true -configwas false -was-server dmgr

The output will be logged to install.log by default. This information center page, Deploying WSRR to federated nodes, shows the installation process.

Figure 4. The Business Process Management golden topology on z/OS
Diagram showing z/OS partition with a Network Deployment Cell containing a Managed Node augmented for Process Server and Deployment Manager Node augmented for Process Server

Creating a backup of the existing cell

Now that you have completed the BPM installation and configuration, you will want to back up your cell's configuration file systems. This section gives an example of how to back up the WebSphere components. For the DB2 components, you should rely on your database administrator to create a proper backup.

The z/OS Distributed File Service System z file systems

All of the WebSphere artifacts necessary to restore the environment in case of a problem live in hierarchical file systems. In this section you see a sample of creating a backup of the System z file systems used to contain the cells configuration data and a sample of how to restore it. Comments in the sample Job Control Language (JCL) explain what each section is attempting to complete.

Backup

Listing 4 shows a sample of backing up the System z file systems for the cell.

Listing 4. Backing up the System z file systems for the cell.
//WT9BACK2 JOB ,CLASS=A,MSGLEVEL=(1,1),MSGCLASS=H,
//*   RESTART=COPYDS2,
//    NOTIFY=&SYSUID,REGION=0M,TIME=1440
//* The 4 definitions below are the names of the datasets to be created
// SET ODSN1=OMVSWS.WT961.JUN1809B.DMP1
// SET ODSN2=OMVSWS.WT961.JUN1809B.WT9NODE.DMP1
// SET ODSN3=OMVSWS.WT961.JUN1809B.WT9JC0.DMP1
// SET ODSN4=OMVSWS.WT961.JUN1809B.WT9JC1.DMP1
//* This step creates a dumped dataset of the first zFS
//COPYDS1  EXEC PGM=ADRDSSU,REGION=0M
//T1  DD DSN=&ODSN1,
//  DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DUMP DS(INCL(                             -
      OMVSWS.WT961.JC0.ZFS                  -
         ))                                 -
       TOLERATE(ENQF) -
       ODD(T1) OPT(4)
//* This step creates a dumped dataset of the second zFS
//COPYDS2  EXEC PGM=ADRDSSU,REGION=0M
//T2  DD DSN=&ODSN2,
//  DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(CYL,(400,100),RLSE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DUMP DS(INCL(                             -
      OMVSWS.WAS61.WT961.WT9NODE.ZFS        -
         ))                                 -
       TOLERATE(ENQF)                       -
       ODD(T2) OPT(4)
//* This step creates a dumped dataset of the third zFS
//COPYDS3  EXEC PGM=ADRDSSU,REGION=0M
//T3  DD DSN=&ODSN3,
//  DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(CYL,(400,100),RLSE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DUMP DS(INCL(                             -
      OMVSWS.WAS61.WT961.WT9JC0.ZFS         -
         ))                                 -
       TOLERATE(ENQF)                       -
       ODD(T3) OPT(4)
//* This step creates a dumped dataset of the forth zFS
//COPYDS4  EXEC PGM=ADRDSSU,REGION=0M
//T4  DD DSN=&ODSN4,
//  DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(CYL,(400,100),RLSE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DUMP DS(INCL(                             -
      OMVSWS.WAS61.WT961.WT9JC1.ZFS         -
         ))                                 -
       TOLERATE(ENQF)                       -
       ODD(T4) OPT(4)

Restore

Listing 5 shows a sample of restoring the System z file systems for the cell.

Listing 5. Restoring the System z file systems for the cell
//WT9REST JOB MSGCLASS=H,CLASS=K,REGION=4M,MSGLEVEL=(1,1), 00010000
//    USER=WITADM1,PASSWORD=adm1wit
//* The 4 datasets created by the backup job
// SET ODSN1=OMVSWS.WT961.JUN1809B.DMP1                                 
// SET ODSN2=OMVSWS.WT961.JUN1809B.WT9NODE.DMP1
// SET ODSN3=OMVSWS.WT961.JUN1809B.WT9JC0.DMP1
// SET ODSN4=OMVSWS.WT961.JUN1809B.WT9JC1.DMP1
//********************************************************************/
//* unmount the existing zFS filesystems
//UNMNT    EXEC  PGM=IKJEFT01,REGION=1024K
//SYSTSPRT DD  SYSOUT=*
//STDOUT   DD  SYSOUT=*
//STDERR   DD  SYSOUT=*
//SYSTSIN    DD  *
 BPXBATCH  SH +
 unmount -o immediate /JC0/wt961/dmnode; +
 unmount -o immediate /JC0/wt961/wt9jc0; +
 unmount -o immediate /JC0/wt961/wt9jc1; +
 unmount -o immediate /JC0/wt961/;
/* delete the zFS filesystems that need replacing
//DELZFS   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSDUMP  DD SYSOUT=*
//AMSDUMP  DD SYSOUT=*
//SYSIN    DD *
 DELETE OMVSWS.WAS61.WT961.WT9NODE.ZFS
 DELETE OMVSWS.WAS61.WT961.WT9JC1.ZFS
 DELETE OMVSWS.WAS61.WT961.WT9JC0.ZFS
 DELETE OMVSWS.WT961.JC0.ZFS
/* restore the dumped datasets to zFS’s
//RST1   EXEC PGM=ADRDSSU,REGION=4096K                                  
//SYSPRINT DD SYSOUT=(H,,STD)                                         
 //SYSABEND DD SYSOUT=(H,,STD)                                           
//IN       DD DISP=SHR,DSN=&ODSN1                                       
//SYSIN    DD *                                                         
 RESTORE DATASET(INCLUDE(OMVSWS.WT961.JC0.ZFS)) -                              
    CATALOG -                                                           
    REPLACE -                                                               
    INDD(IN) -                                                          
    TOL(ENQF) -                                                   
    STORCLAS(SMSOE) -                                                       
    MGMTCLAS(SMSOE) -                                                   
    WRITECHECK      
/*                                                                      
//RST2   EXEC PGM=ADRDSSU,REGION=4096K
//SYSPRINT DD SYSOUT=(H,,STD)
//SYSABEND DD SYSOUT=(H,,STD)
//IN       DD DISP=SHR,DSN=&ODSN2
//SYSIN    DD *
 RESTORE DATASET(INCLUDE(OMVSWS.WAS61.WT961.WT9NODE.ZFS)) -
   CATALOG -
   REPLACE -
   INDD(IN) -
   TOL(ENQF) -
   STORCLAS(SMSOE) -
   MGMTCLAS(SMSOE) -
   WRITECHECK
/*
//RST3   EXEC PGM=ADRDSSU,REGION=4096K
//SYSPRINT DD SYSOUT=(H,,STD)
//SYSABEND DD SYSOUT=(H,,STD)
//IN       DD DISP=SHR,DSN=&ODSN3
//SYSIN    DD *
 RESTORE DATASET(INCLUDE(OMVSWS.WAS61.WT961.WT9JC0.ZFS)) -
   CATALOG -
   REPLACE -
   INDD(IN) -
   TOL(ENQF) -
   STORCLAS(SMSOE) -
   MGMTCLAS(SMSOE) -
   WRITECHECK
/*
//RST4   EXEC PGM=ADRDSSU,REGION=4096K
//SYSPRINT DD SYSOUT=(H,,STD)
//SYSABEND DD SYSOUT=(H,,STD)
//IN       DD DISP=SHR,DSN=&ODSN4
//SYSIN    DD *
 RESTORE DATASET(INCLUDE(OMVSWS.WAS61.WT961.WT9JC1.ZFS)) -
   CATALOG -
   REPLACE -
   INDD(IN) -
   TOL(ENQF) -
   STORCLAS(SMSOE) -
   MGMTCLAS(SMSOE) -
   WRITECHECK
/*
//REMNT    EXEC  PGM=IKJEFT01,REGION=1024K
//SYSTSPRT DD  SYSOUT=*
//STDOUT   DD  SYSOUT=*
//STDERR   DD  SYSOUT=*
//SYSTSIN    DD  *
 BPXBATCH  SH +
 mount -t ZFS -d JC0 -a no -f OMVSWS.WT961.JC0.ZFS /JC0/wt961; +
 mount -t ZFS -d JC0 -a no -f OMVSWS.WAS61.WT961.WT9NODE.ZFS +
       /JC0/wt961/dmnode; +
 mount -t ZFS -d JC0 -a no -f OMVSWS.WAS61.WT961.WT9JC0.ZFS +
       /JC0/wt961/wt9jc0; +
 mount -t ZFS -d JC0 -a no -f OMVSWS.WAS61.WT961.WT9JC1.ZFS +
       /JC0/wt961/wt9jc1;

The DB2 artifacts and data

Important: You will have to unload data from residing in the tablespace. Data only resides in tablespaces, index spaces and AUX tablespaces associated with LOBs. If you have LOBs, they will add a new wrinkle to this process.

Make sure to tell your database administrator that the data has LOBs when you request a backup of the data.

Since there is Large Object (LOB) data involved the backup and restore of the database artifacts, in this document we describe how to backup and restore database document but do not give any samples.

Your database administrator should know how to create a backup of the necessary databases. With this section of the article we want to point out that you need to create a regular backup of the database and data for your business process management cell.


Conclusion

This article guided you through several processes: configuration of the products that make up the business process management stack on the z/OS operating system as well as back-up and recovery of the file systems that make up the cell and database. Throughout the article you were pointed to the documentation that helped complete these tasks. You were given all the information we found necessary to complete the journey.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, Information Management
ArticleID=462144
ArticleTitle=Installing and configuring the 6.1.2 business process management stack on z/OS
publish-date=01182010