You can use a number of ESQL statements and functions to access databases: INSERT statement The INSERT statement

adds a row to a database table. UPDATE statement The UPDATE statement changes one or more values stored in zero or more rows. DELETE FROM statement The DELETE FROM statement removes zero or more rows. SELECT function The SELECT function retrieves data from a table. CALL statement The CALL statement invokes a stored procedure. PASSTHRU statement The PASSTHRU statement can be used to invoke administrative operations, such as creating a table. PASSTHRU function The PASSTHRU function can be used to invoke complex selects. You can access user databases from Compute, Database, and Filter nodes; you can use the same ESQL statements and functions to access databases in all three types of node. A single node can access multiple databases but the following restrictions apply: Any node that accesses one or more databases must have its Data source property set with the ODBC data source name (DSN) of a database; the database must be accessible and operational, and the broker must be authorized to connect to it. All databases that are accessed from a single node must be compatible with each other. If you use the same database manager on the same platform at the same service level for all the databases, the data sources will be compatible. For example, two DB2 database instances at the same DB2 fix pack level are compatible but a DB2 database and an Oracle database are not compatible. If you use data sources that are not compatible, when you put a message through the message flow to test it, the message flow throws an error. If your data sources are not compatible, you cannot access them from a single node; if this is the case, use additional nodes in your message flow. All tables that are referred to in a single SELECT functions FROM clause must be in the same database.

To access databases, you must ensure that suitable ODBC data source names (DSN) have been defined on the system on which the broker is running. On Linux on System z and Linux on POWER, the only supported database manager is DB2 and ODBC is not used; the broker and

message flows connect to the databases directly. When you configure message flows, use the DB2 alias of the database as the DSN. If you have used the mqsisetdbparms command to set a user ID and password for a particular database, the broker uses these values to connect to the database. If you have not set values for a particular database, the broker uses the default database user ID and password that you supplied on the mqsicreatebroker command, or the user ID and password details that you specified if you have modified the broker using the mqsichangebroker command.

User database connections

User databases contain your business data that is written and accessed by deployed message flows. You must create connections from the broker to the user database using ODBC or JDBC. The broker requires a database connection for each data source name (DSN) that is referenced in the message flow, even if different DSNs resolve to the same physical database. The number of connections to a user database that a broker requires depends on the actions of the message flows that access the database. For each message flow thread, a broker that accesses a user database makes one connection for each data source name (DSN). If a different node on the same thread uses the same DSN, the same connection is used, unless a different transaction mode is used, in which case another connection is required. For further information about transactions, see Database connections for coordinated message flows. When you start a broker, and while it is running, it opens connections to WebSphere MQ queues and to databases. The broker makes the connections when it needs to use them, and they remain open until: The message flow has been idle for one minute The message flow is stopped The broker is stopped Database connections from message flows that are not globally coordinated are released when a flow has no work. For example, a connection is released if the message flow input queue has no messages, and the database has not been accessed for one minute. On Linux, UNIX, and Windows systems, to avoid breaking global coordination, database connections are released only for message flows that are not globally coordinated. On z/OS, database connections for globally-coordinated message flows are also released if the database has not been accessed for one minute. If you are using the same database for business data and for broker internal data, add the two connection requirements together when you calculate how many connections are required. For details of broker database connection requirements, see Broker database connections.

If you are using DB2 for your database, the default action is to limit the number of concurrent connections to a database to the value of the maxappls configuration parameter. The default for maxappls is 40. If you believe that the connections that the broker might require exceeds the value for maxappls, increase this and the associated parameter maxagents to new values based on your calculations. If you are using another database, check the database documentation for information about connections and the limits or restrictions that might apply. When a message flow is idle, the execution group periodically releases database connections. Therefore, connections held by the broker reflect the broker's current use of these resources. This situation allows the broker to respond when a database quiesces, provided that the database manager supports quiescing. Not all databases support the quiesce function, and not all databases quiesce in the same way. Check your database documentation for information about database quiescing.

Broker database connections

Create connections from each broker to its database using ODBC. Broker components and execution groups read and write data about internal operations to a broker database. The number of connections needed depends on the actions of the message flows that the broker processes. Each broker needs the following connections: Five for internal broker threads. One for each Publish/Subscribe neighbor, if you are using retained publications and the topology has been deployed. One for each message flow thread that contains a Publication node, if you are using retained publications. One for each message flow thread that parses MRM messages. A further number if you are using SCADA nodes with WebSphere MQ Everyplace. The exact number to add depends on whether thread pooling is being used (determined by the Use Thread Pooling property of the SCADAInput node): o If Use Thread Pooling is not selected (the default setting) add the number of SCADA clients that will connect to the SCADAInput node. o If Use Thread Pooling is selected, add the value in the Max Threads property of the SCADAInput node. The default value is 500.

If you are using the same database for several brokers, include all brokers in your calculations. When you start a broker, it opens all connections that it needs to the broker database for its own operation. When you stop the broker, it releases all current database connection handles. The broker also opens connections to WebSphere MQ queues and to user databases when it needs to use them, and these connections remain open until: The connection has been idle for one minute The broker is stopped

On Linux, UNIX, and Windows systems, to avoid breaking global coordination, database connections are released only for message flows that are not globally coordinated. On z/OS, database connections for globally coordinated message flows are also released if the database has not been accessed for one minute. If you are using DB2 for your database, the default action taken by DB2 is to limit the number of concurrent connections to a database to the value of the maxappls configuration parameter. The default for maxappls is 40. Increase this parameter and the associated parameter maxagents to new values based on your calculations, if appropriate.

Enabling ODBC connections to the databases

Set up the resources and environment that the broker needs to connect to broker and user databases with ODBC. The broker uses Open Database Connectivity (ODBC) to connect to the broker database. You must define ODBC data source names (DSNs) for the broker database on each computer that hosts a broker. You can configure both ODBC and Java Database Connectivity (JDBC) connections for access to user databases. To set up ODBC connections to the broker database, and to user databases, follow the instructions in this section. For JDBC connections to user databases, see Enabling JDBC connections to the databases. On z/OS systems, see Data sources on z/OS for information about enabling connections to databases. You do not have to follow the tasks described in this section. On Linux and UNIX systems, the actions that you must take to define the connections between the broker and the broker database depend on whether the broker core components operate in 32-bit or 64-bit mode. You must define either a 32-bit ODBC DSN, or a 64-bit ODBC DSN, as appropriate, for the broker to connect to the broker database. All execution groups that you create on a broker must also be able to connect to the broker database. If the execution group matches the operational mode of the broker core, the execution group can connect to the broker database using the same DSN definition that the broker uses. If a 64-bit broker also supports 32-bit execution groups (for example, AIX), you must also define a 32-bit ODBC connection to support connections from 32-bit execution groups to the broker database. This 32-bit connection is required in addition to the 64-bit ODBC definition, even if you do not create 32-bit execution groups. Because 64-bit connections need 64-bit database instances, you can use 32-bit database instances only on computers with a 32-bit broker core. Migrate all 32-bit database instances to 64-bit instances on all 64-bit platforms. On distributed systems, when you define the DSNs, consider the following two factors that determine whether you must define a 32-bit DSN for the database, a 64-bit DSN, or both:

Whether the execution group and the database instance operate in 32-bit or 64-bit mode Whether you plan to globally coordinate message flow transactions