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 188.8.131.52
- IBM WebSphere Process Server V184.108.40.206
- IBM WebSphere Business Services Fabric Version 220.127.116.11
- IBM WebSphere Service Registry and Repository Version 18.104.22.168
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.
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
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
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
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
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:
- Gather required DB2 information for creating BPM supporting databases.
- Install Process Server into the cell's deployment manager
- Create the Process Server Common Database
- Install Process Server into the managed node
- Federate the empty node into the deployment manager cell.
- Create a process server cluster.
- Create the messaging engine data sources.
- Configure SCA.
- Configure Business Process Choreographer.
- Configure Common Event Infrastructure.
- Install Business Services Fabric application into the cell
- Install the Services Registry and Repository application into the cell.
Configuring the DB2 environment
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:
- Set up new buffer pools to use for the Process Server databases and tablespaces.
- Determine the proper storage group.
- Determine the appropriate segment size for tablespaces.
- Determine the primary storage size.
- 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 Name||Size||Description|
Used to store user data.
Used for indexes.
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
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:
- Create and populate the DB2 database using the createDB.sh script
- Create and populate the DB2 database using DBUtility.sh, SPUFI, or DSNTEP2
Installing Process Server into the deployment manager
The process is broken down into several steps:
- Install the Process Server code into the deployment manager.
- Augment the deployment manager profile.
- Create the common database objects.
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
Our sample cell deployment manager is installed to
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:
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
- Creation of
BusinessSpacedirectories 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:
Since you will need to modify this file, copy it to your current working directory.
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:
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:
- Augments the deployment manager profile indicated in the response file with the following profile templates:
- Indicates the augmented profile with properties
profilePathin the response file
- Generates a set of SQL scripts in the deployment manager's dbscripts directory.
DBNAMEare 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
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.
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
Creates two tablespaces and one LOB tablespace
Creates one tablespace
Creates two tablespaces and two LOB tablespaces
Creates one tablespace and one LOB tablespace
Creates on tablespace
Creates two tablespaces and four LOB tablespaces
Creates one tablespace
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;
<DBNAME> is the value of the
SQLDB parameter from your
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:
- Install the Process Server code into the node
- Augment the node profiles
- 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
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.
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.
- Configuring the response file: You can locate a sample script at:
- 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
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.
- Log on to the z/OS system on which you intend to federate the server.
- Start the Customization Dialog.
- Choose the configuration data sets in which you will store your customization jobs and data.
- Load the common MVS groups and users variables.
- 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:
- Create the customization jobs and files, based on the customization variable values you entered.
- 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
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.
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.
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.
- 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.
- Check the box titled Support the Service Component Architecture components.
- Verify and update the settings in the System Bus Member box.
- Verify and update the settings in the Application Bus Member box.
- 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).
- 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.
- Log into the administrative console, and browse to: Servers > Clusters > Cluster Name > Container Settings > Business Process Choreographer Container Settings > Business Process Choreographer Containers
- Check the box titled Support the Service Component Architecture components.
- Verify and update the settings in the System Bus Member box .
- Verify and update the settings in the Application Bus Member box .
- Enable and install BPC Explorer by selecting: Servers > Clusters > Cluster Name > Container Settings > Business Process Choreographer Container Settings > Business Process Choreographer Explorer.
- Add the cluster to target table.
Validating the Business Process Choreographer installation
Process Server provides an initial verification test, located in
Install this application choosing all default values during the installation process
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
- Log in to the Administrative Console, and browse to Servers > Clusters > Cluster Name > Business Integration > Commen Event Infrastructure > Common Event Infrastructure Server.
- Enable the common event infrastructure server.
- 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:
- Create the databases.
- Run a series of JACL scripts.
- Create JDBC resources.
- Create JMS resources.
- Create J2C authorization aliases.
- Install the applications.
Adding Service Registry and Repository to the Cell
Activation of Service Registry and Repository consists of the following steps:
- Copy the installed binary directory to the working deployment directory.
- Create the databases
- Run a script to copy the DB2 SQL and Job Control Language to datasets.
- Deploy Service Registry and Repository for z/OS
- 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:
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
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
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
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.
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)
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
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.
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.
- WebSphere Process Server Version 6.2.0 - Configuring the Process Choreographer and other BPM components in a clustered environment
- Building an end-2–end business solution
- WebSphere Process Server Information Center
- WebSphere Application Server Information Centers
- developerWorks BPM zone
- developerWorks WebSphere on System z zone
- IBM Business Process Management.
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.