Coordinating your DB2CONN, DB2ENTRY, and BIND options

In general, you are recommended to set the initial values for your DB2CONN, DB2ENTRY, and BIND options to the values shown in Table 1. You might find that you get better performance from other combinations for your own transactions. For each transaction type a recommended thread type and BIND option are shown. There are also recommendations for whether transactions overflow to the pool.

In Table 1 limited concurrency means only a limited number (n) of transactions are allowed to run at the same time. A special case exists when n=1, in this case the transactions are serialized. You can still use a protected thread if the transaction rate is high enough to make it worthwhile. The transactions cannot be controlled, if overflow to the pool is allowed. You are recommended to use the CICS® mechanism for limiting the number of transactions running in a specific class, rather than forcing transactions to queue for a limited number of threads.

As Table 1 shows, a few combinations of DB2CONN, DB2ENTRY, and BIND options are generally recommended. However, in specific situations other combinations can be used.

Table 2 shows a summary of the activities involved in processing SQL requests for the three recommended sets of DB2CONN, DB2ENTRY, and BIND specifications. The table also demonstrates the performance advantage of using protected threads without changing the authorization ID. Required activities are marked as follows in the table:

X

Required activity

(1)

Required only if new authorization ID

(2)

Required only if SQL section is not already in EDM pool

(3)

Required only if SQL section is not already in Cursor Table