Before you create the IBM® Business Process Manager databases, you must ensure that the required authorizations are granted for your DB2® for z/OS® version. Also ensure that the appropriate storage groups and buffer pools are assigned, and configure clustering if necessary.
User authorization requirements for DB2 for z/OS
Ask your DB2 for z/OS system administrator to check the authorizations that have been granted to ensure that you have not granted more authority than necessary to any user ID. It can be tempting to grant DB2 SYSADM authority to the JCA authentication aliases in order to avoid possible problems with DB2 security during the configuration. The WebSphere® administrator ID should not require more than DBADM authority to define the IBM Business Process Manager databases.
GRANT USE OF STOGROUP #STOGRP# TO #DB_USER# WITH GRANT OPTION;
GRANT DBADM ON DATABASE #DB_NAME# TO #DB_USER#;
GRANT USE OF ALL BUFFERPOOLS TO #DB_USER#;GRANT CREATEIN,ALTERIN,DROPIN ON SCHEMA #SCHEMA# TO #DB_USER# WITH GRANT OPTION;GRANT CREATE ON COLLECTION #SCHEMA# TO #DB_USER#;
GRANT BINDADD TO #DB_USER#;Authorization requirements for views on DB2 for z/OS V10
- Before you run the SQL to define views, you might need to set
the DBACRVW subsystem parameter to YES.
This setting ensures that WebSphere administrator IDs with DBADM authority on database #DB_NAME# can create views for other user IDs.
- On DB2 for z/OS V10, the WebSphere administrator ID must be specifically
granted access to views, because access is not implicitly granted
to users with DBADM authority on the database. Individual GRANT statements
or a Resource Access Control Facility (RACF®)
group can be used to provide access to views in DB2 for z/OS V10.
Ask your DB2 for z/OS administrator to provide this access by
using either of the following methods:
- Issue an explicit GRANT statement for each view. For example,
the following sample GRANT statements can be issued for user ID WSADMIN:
GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ACTIVITY TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ACTIVITY_ATTRIBUTE TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ACTIVITY_SERVICE TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.APPLICATION_COMP TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.AUDIT_LOG TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.AUDIT_LOG_B TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.BUSINESS_CATEGORY TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.BUSINESS_CATEGORY_LDESC TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ESCALATION TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ESCALATION_CPROP TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ESCALATION_DESC TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ESC_TEMPL TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ESC_TEMPL_CPROP TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.ESC_TEMPL_DESC TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.EVENT TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.MIGRATION_FRONT TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.PROCESS_ATTRIBUTE TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.PROCESS_INSTANCE TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.PROCESS_TEMPLATE TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.PROCESS_TEMPL_ATTR TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.QUERY_PROPERTY TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.QUERY_PROP_TEMPL TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.SHARED_WORK_ITEM TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_AUDIT_LOG TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_CPROP TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_DESC TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_HISTORY TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_TEMPL TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_TEMPL_CPROP TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.TASK_TEMPL_DESC TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.WORK_BASKET TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.WORK_BASKET_DIST_TARGET TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.WORK_BASKET_LDESC TO WSADMIN WITH GRANT OPTION; GRANT DELETE,INSERT,SELECT,UPDATE ON TABLE S1CELL.WORK_ITEM TO WSADMIN WITH GRANT OPTION; - Define a RACF group that
corresponds to the schema name for the views, and connect the WebSphere administrator ID
to the RACF group. For example,
you can define a RACF group
named S1CELL, and connect user WSADMIN to it, as follows:
INFORMATION FOR GROUP S1CELL SUPERIOR GROUP=ZWPS OWNER=ZWPS CREATED=07.144 INSTALLATION DATA=OWNED BY EMP SERIAL 009179, SITE ABCUK NO MODEL DATA SET TERMUACC NO SUBGROUPS USER(S)= ACCESS= ACCESS COUNT= UNIVERSAL ACCESS= WSADMIN CONNECT 000000 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE
- Issue an explicit GRANT statement for each view. For example,
the following sample GRANT statements can be issued for user ID WSADMIN:
Using the configuration planning spreadsheet to define authorizations
If you have downloaded the configuration
planning spreadsheet for use, you can alternatively use this spreadsheet
to generate the GRANT permissions that are required for users and
for DB2 for z/OS V10 views (as identified in the preceding
sections in this topic). The configuration planning spreadsheet is
available from 
Techdoc WP102075 in
the IBM Support Portal.
The Database worksheet in the spreadsheet lists a set of sample SQL statements that can be used to create the databases and storage groups. Additionally, the GRANT permissions that are required to authorize the WebSphere administrator and to provide access to DB2 for z/OS V10 database tables are provided. When you specify the user and database object names on the BPMVariables worksheet of the spreadsheet, these values are propagated to the Database worksheet, and are used to complete the CREATE and GRANT statements with the appropriate values.
Ask your DB2 for z/OS system administrator to use the relevant CREATE statements to create the databases and storage groups, and to use the GRANT statements to authorize the WebSphere administrator. For more information about using the artifacts generated from the spreadsheet, see the accompanying PDF document in the Techdoc.
Storage group assignments and buffer pool usage
Ask your DB2 for z/OS system administrator to check the storage group assignments and buffer pool usage. Incorrect storage group assignment and buffer pool usage might not show up as an error message in a log, but might cause problems later. It is better to resolve such problems now rather than when the system has been handed over for use. For example, correcting storage groups and VCATs is not easy after the tables and indexes have been used.
Clustering requirements
If you intend to configure clustering, your DB2 for z/OS system must be running in data-sharing mode.