This is part of the larger task of customizing your z/OS environment and is relevant only to the broker component. The Configuration Manager and User Name Server do not require access to DB2.
WebSphere Message Broker for z/OS accesses DB2 tables using ODBC. To connect to DB2 using ODBC, the location name of the DB2 subsystem is used. See the DB2 UDB for OS/390® and z/OS V7 Data Sharing: Planning and Administration manual for more details.
When your DB2 system starts up there should be a message DSNL004I DDF START COMPLETE. The location name is displayed just after this message. When you customize a broker component on z/OS you create a dsnaoini file called BIPDSNAO in the broker PDSE. It contains necessary information to establish the ODBC connection. See the DB2 UDB for OS/390 and z/OS V7 ODBC Guide and Reference manual for more details.
You should avoid using a data source name that is the same as the subsystem ID or data sharing ID. If the same name is used, this might affect the granularity of directives on connection with the database.
If you choose to use the same value for the data source name and subsystem ID, you must edit BIPDSNAO in the broker PDSE so that the Datasource and Subsystem keywords are in one section.
See the DB2 UDB for OS/390 and z/OS V7 ODBC Guide and Reference manual for more information on customizing this file.
select * from SYSIBM.SYSPACKLIST where planname ='DSNACLI';You should rebind if the location column is blank and not '*'.
You should also check that DSNACLI is in the SYSIBM.SYSPLAN table.
You will get significant performance benefits from using the CACHE DYNAMIC SQL facility of DB2, because this eliminates the need to reprocess DB2 statements. See CACHEDYN=YES in the DB2 UDB for OS/390 and z/OS V7 Installation Guide.
You can use the DB2 security mechanism, or if on z/OS 1.5 and DB2 Version 8 use an external security manager, for example, RACF.
DB2 security mechanism
GRANT DELETE, INSERT, SELECT, UPDATE ON TABLE DB2_TABLE_OWNER.BSUBSCRIPTIONS ,DB2_TABLE_OWNER.BPUBLISHERS ,DB2_TABLE_OWNER.BCLIENTUSER ,DB2_TABLE_OWNER.BTOPOLOGY ,DB2_TABLE_OWNER.BNBRCONNECTIONS ,DB2_TABLE_OWNER.BRETAINEDPUBS ,DB2_TABLE_OWNER.BACLENTRIES ,DB2_TABLE_OWNER.BMQPSTOPOLOGY ,DB2_TABLE_OWNER.BUSERNAME ,DB2_TABLE_OWNER.BGROUPNAME ,DB2_TABLE_OWNER.BUSERMEMBERSHIP ,DB2_TABLE_OWNER.BROKERAA ,DB2_TABLE_OWNER.BROKERAAEG ,DB2_TABLE_OWNER.BROKERRESOURCES ,DB2_TABLE_OWNER.BRMINFO ,DB2_TABLE_OWNER.BRMRTDINFO ,DB2_TABLE_OWNER.BRMRTDDEPINFO ,DB2_TABLE_OWNER.BRMWFDINFO ,DB2_TABLE_OWNER.BRMPHYSICALRES ,DB2_TABLE_OWNER.BAGGREGATE ,DB2_TABLE_OWNER.BMULTICASTTOPICS TO MQP1USR; GRANT SELECT ON TABLE SYSIBM.SYSTABLES ,SYSIBM.SYSSYNONYMS ,SYSIBM.SYSDATABASE TO MQP1USR;
If this Id is a group, then DB2 checks to see if your user Id is connected to this group, and if it is, you inherit the access from the group; if the user Id is not in the group, you get SQL code -551.
If your Id is in multiple groups, then the highest authorities are used.
If this Id is a group, then DB2 checks to see if your user Id is connected to this group, and if it is, you inherit the access from the group; if the user Id is not in the group, you get SQL code -551. If your Id is in multiple groups, then the highest authorities are used.
If you do not use groups to define permissions, but use a specific user ID to define the permissions to individual user Ids, then, if the granting user Id is removed from DB2 any permissions that it gave are also removed. This can prevent other users working.
See z/OS utility jobs for further information on the WebSphere Message Broker for z/OS jobs that are supplied.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ae22130_ |