A broker stores internal performance and operational data in a database that you must create and configure before you create the broker. You might also choose to access databases to hold application or business data.
Multiple
brokers that are at the same version can store their tables in a single
database schema, if appropriate, even if they are not on the same
computer.
Databases that hold application or business data are known as user databases, and are read from and written to by nodes within the message flows that you deploy to one or more brokers in your domain.
In some situations, the data that you hold in user databases might be critical to the success of your applications, and a particular step in their processing. You might therefore need to coordinate table updates, or the writing to one database with the deletion of data in another. To achieve these goals, you must configure your databases, your brokers, and your message flows to be globally coordinated.
For more information about the requirement for, and set up of, broker and user databases, and the restrictions that apply, see Databases overview.
For
additional information about setting up databases on z/OS®, see DB2 planning on z/OS and Customizing the z/OS environment.
The process of making databases available has the following phases:
If you are migrating from a previous release, you can continue to use the same broker database, but you must check and update your ODBC configuration to ensure continued database access. Database access requires different configuration in each release; see Migrating from Version 5.0 products or Migrating from Version 2.1 products.
If you are not migrating, you must create and configure a database for each broker that you create, and you must configure the ODBC resources required by the broker to connect to that database.
Optional: if you want to deploy publish/subscribe message flow applications, and you have created a broker database on a Sybase database instance, you must modify the database to operate successfully in this environment.
On distributed systems, the WebSphere MQ queue manager is the transaction manager that interacts with the resource managers (the database providers). On z/OS, RRS provides equivalent coordination.
To complete these phases: