After creating the database scripts for the IBM® Business Process Manager components,
you can run the createDB2.sh script to create one
or more databases in the DB2® for z/OS® subsystem and populate each
database with objects.
You
can also use tools such as the DB2 command
line processor, SPUFI, or DSNTEP2 to create and populate databases.
Before you begin
- Decide on the DB2 for z/OS database
design and configuration, including the number of databases required
for the IBM Business Process Manager components.
For example, in a stand-alone server environment, you might decide
to set up all the component databases in a single DB2 for z/OS database.
Or, in a network deployment environment, you might define two DB2 for z/OS databases, where one database is used for
the Common database component, which is cell-scoped, and another database
is used for all the other components, which are cluster-scoped.
- Decide on a naming convention for the DB2 for z/OS objects, such as databases, storage groups,
VSAM catalog names (VCATs), schema prefixes, buffer pools, and security
IDs.
- Configure the stand-alone server or
network deployment environment. When you configure the nodes, ensure
that the dbDelayConfig parameter in the augmentation
response file is set to true.
- Create the required buffer pools. For
more information, see Sample DB2 commands
and SQL.
- Run the database design tool (DbDesignGenerator.sh)
to generate the database scripts that are used to create the database
objects for the IBM Business Process Manager components.
Set up your database configuration so that the database design tool
creates a single output directory for each database to be created,
and generates all the relevant database scripts, including the createDB2.sh script,
which are required to create the database, into that directory.
- Configure the DB2 command line processor.
About this task
The number of databases that you create for your
IBM Business Process Manager installation
can depend on your configuration (stand-alone or network deployment),
and how you want to distribute your database objects across the DB2 for z/OS subsystem.
Provided that the database scripts are grouped
appropriately in the output directories that were specified when you
ran the database design tool, you can run the createDB2.sh script
once for each instance of a database to be created. For
example:
- To create a single database, you can run createDB2.sh once
from a directory that contains all the database scripts that were
generated for all the IBM Business Process Manager components.
- To create multiple databases at the cell level and cluster levels,
you can run createDB2.sh once from each directory
that contains the database scripts required to create the database
objects for the cell and clusters.
In a sysplex environment where the database
is not shared across the sysplex, and IBM Business Process Manager and DB2 for z/OS are installed on different LPARs, you must
run createDB2.sh on the system that has the installation
of DB2 rather than the one that
has the installation of IBM Business Process Manager.
Important: It is anticipated
that the DB2 for z/OS system administrator will run the createDB2.sh script
with a user ID that has SYSADM authority, to create the databases
and storage groups. On completion, the system administrator can then
grant DBADM authority for the IBM Business Process Manager databases
to the WebSphere® administrator.
Procedure
Complete the following steps for each database that you
want to create:
- In the z/OS system that contains the IBM Business Process Manager installation,
or the DB2 installation on a
different LPAR, access the UNIX System
Services command shell. Then change to the directory to which the
database scripts were generated. For example:
cd /WebSphere/V8T3Z1/AppServer/profiles/default/dbscripts/S4CELLDB
- Run the createDB2.sh script
by using the following syntax:
createDB2.sh -DBAlias alias_name -DBName database_name -DBSto storage_group_name -DBCreate
-DBVCat volume_catalog -DBUser DB_user_ID -RunSQL
where:
- -DBAlias
- Specifies an alias name, which maps to the DB2 server URL, user ID, and password, and which
is used to connect to DB2. If
you do not specify this parameter when you run the createDB2.sh script,
you are prompted for a value.
- -DBName
- Specifies the name of the database to be created.
- -DBSto
- Specifies the storage group name for the volumes that hold the
data sets where tables and indexes are stored.
- -DBCreate
- Creates the database.
- -DBVCat
- Specifies the name of the DB2 Virtual
Storage Access Method (VSAM) catalog that records information about
the data sets.
- -DBUser
- Specifies the user ID of the WebSphere administrator
that has database administration authority for the IBM Business Process Manager database
being created.
- -RunSQL
- Runs the SQL statements that create the database objects.
For example:
createDB2.sh
-DBAlias DSNXWBD -DBName S4CELLDB -DBSto S4DBSTO -DBCreate -DBVCat
DSNV10PP -DBUser S4ADMIN -RunSQL
For information about all the
parameters that are available for the createDB2.sh script
and example usage, see createDB2.sh script.
- Review the messages that are
displayed in the console, checking that no error messages are displayed.
Tip: The first time that you run createDB2.sh to
create the database, you see a few messages because the script first
attempts to drop the database, which at that stage does not yet exist.
These messages can be ignored, and subsequent invocations of createDB2.sh for
the same database will not produce such messages.
When the
script has finished running, you can also review the z_output.txt file,
which provides an audit trail of the operations completed and status
messages. This file is stored in the directory from which you ran
the createDB2.sh script.
Results
Each database is created and populated
with the required database objects.
What to do next
For a stand-alone configuration,
complete the remaining database configuration tasks, if relevant. Then run the bootstrap utility to load the database
with system information.
For a network deployment configuration,
complete the remaining database configuration tasks, if relevant.
Then start the deployment manager server.