WebSphere Message Brokers
File: ae14070_
Writer: Stephanie J Strugnell

Task topic

This build: July 31, 2007 21:27:43

Setting up DB2 security on z/OS

This is part of the larger task of setting up security on z/OS.

The user ID of the person running the DB2 configuration jobs must have UPDATE access to the component PDSE, READ/EXECUTE access to the installation directory, and READ/WRITE/EXECUTE access to the broker-specific directory.

A user needs SYSADM or SYSCTRL authority to run the DB2 configuration jobs.

You cannot share DB2 tables between brokers; each broker must have its own DB2 tables. The format of the table names is:
table_owner.table_name
where table_owner is known as the table owner.
When the broker starts up, the started task user ID is used to connect to DB2 using ODBC. The ODBC statement Set current SQLID is used to set the ID to table_owner; the table owner ID specifies which tables to use. You have two options in setting up the IDs:
  1. Make the table owner the same as the started task user ID. This means that each broker must have a different user ID. Check that the started task user ID specified has access to SYSIBM tables. From a TSO user with no system administration authority, use SPUFI to issue the following commands:
    select	*	      from	SYSIBM.SYSTABLES; 
    select	*	      from	SYSIBM.SYSSYNONYMS;
    select	*	      from	SYSIBM.SYSDATABASE;
    and resolve any problems.
  2. Make the table owner different from the started task user ID. For this to work the started task needs to be able to issue the Set current SQLID request. The easiest way to do this is to create a RACF group with the same name as the table owner, and connect the started task user ID to this group.
    Check that the group ID specified has access to SYSIBM tables. From a TSO user with no system administration authority, use SPUFI to issue the following commands:
    SET	   CURRENT	SQLID='WMQI'; 
    select	*	from	  SYSIBM.SYSTABLES; 
    select	*	from	  SYSIBM.SYSSYNONYMS;
    select	*	from	  SYSIBM.SYSDATABASE;
    and resolve any problems (WMQI is the name of the group). You might need to connect the TSO user IDs of the DB2 administrators to the group.

    If you have a unique group for each broker (and not a unique started task user ID), the started task user ID must be connected to the group for the ODBC request set currentsqlid to work successfully.

The DB2 administrator user ID must have access to one of the programs DSNTEP2 or DSNTIAD, or equivalent.

The started task user ID must be authorized to connect to DB2. The started task user ID needs a minimum of READ access to the subsystem.RRSAF profile in the DSNR class, if present. In this case, subsystem is the DB2 subsystem name. For example, the following RACF command lists all the resources in DSNR class:
RLIST DSNR *  

The started task user ID needs EXECUTE authority to the DSNACLI plan or equivalent.

The DB2 subsystem started task user ID needs authority to create data sets with the high level qualifier specified in the DB2_STOR_GROUP_VCAT value.

Related concepts
Security overview
Related tasks
Setting up z/OS security
Setting up WebSphere MQ
Setting up workbench access on z/OS
Creating Publish/Subscribe user IDs
Security considerations on z/OS
Related reference
Customization tasks and roles on z/OS
Summary of required access (z/OS)
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:27:43

ae14070_ This topic's URL is: