Start of change

DB2 planning (z/OS)

This is part of the larger task of customizing your z/OS environment.

WebSphere Business Integration 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.

WebSphere Business Integration Message Broker for z/OS customization creates an ODBC initialization file, DSNAOINI. 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 DSNAOINI in the broker directory so 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.

During customization you can specify which plan name to use, or use the default DSNACLI. If you want your broker to access DB2 data-sharing groups other than its own, the DSNACLI plan must be bound in a special way. Check the wildcard location is specified by using SPUFI and issuing the following command:
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.

If your user database is configured to use a comma as a decimal separator using the DSNHDECP module, you will find there is a restriction. If there is a mismatch between DB2 and the locale settings of the user ID under which the broker runs (specifically LC_NUMERIC), your user database updates can be unpredictable. LC_NUMERIC is set through the LC_ALL setting in the mqsicompcif file. The following list details the four possibilities:
  • If DB2 is configured to use a period as a decimal point and LC_NUMERIC is set to a value that indicates a period decimal point; user database updates should work correctly.
  • If DB2 is configured to use a comma as a decimal point and LC_NUMERIC is set to a value that indicates a comma decimal point; user database updates should work correctly.
  • If DB2 is configured to use a period as a decimal point and LC_NUMERIC is set to a value that indicates a comma decimal point; user database updates can lead to unpredictable behavior.
  • If DB2 is configured to use a comma as a decimal point and LC_NUMERIC is set to a value that indicates a period decimal point; user database updates can lead to unpredictable behavior.
Related tasks
Customizing the z/OS environment
Related reference
Customization tasks and roles (z/OS)
Binding a DB2 plan to use data-sharing groups


End of change