Overview: How you can define the CICS DB2 connection

DB2CONN

DB2CONN is the main definition for the CICS DB2 connection. You must install a DB2CONN resource definition before you can start the CICS DB2 connection. You use the DB2CONN definition to define the following items:

• The attributes of the overall CICS DB2 connection:
  • The DB2 subsystem to which CICS connects, or the data-sharing group of DB2 subsystems from which DB2 picks an active member for CICS to connect to.
  • If the connection to DB2 fails, whether CICS reconnects automatically or not, and, if you are using the group attach facility, whether CICS reconnects to the same DB2 subsystem or not.
  • A general-purpose authorization ID for the CICS DB2 attachment facility to sign on to a thread, if no other authorization is needed for the thread.
  • The limit on the total number of TCBs that CICS can use to run threads into DB2 at any one time.
  • How long protected threads are kept before termination.
  • The limit on the number of times a thread can be reused before being terminated.
  • How error messages are communicated to CICS, and what transactions should do if their thread fails.
  • Where messages and statistics are sent.
• The attributes of command threads, which are the special threads used by the DSNC transaction for issuing DB2 commands:
  • The limit on the number of command threads that CICS can use at any one time.
  • What type of authorization ID DB2 checks when a command thread is requested (for example, the ID of the user, the ID of the transaction, and the general-purpose CICS DB2 attachment facility ID).
• The attributes of pool threads, which are the general-purpose threads that are used when transactions do not need a special command or entry thread, or when there are no special threads left for a transaction to use:
  • What type of authorization ID DB2 checks when a pool thread is requested (for example, the ID of the user, the ID of the transaction, the general-purpose CICS DB2 attachment facility ID).
  • What the priority of the thread TCBs is relative to the CICS main TCB.
  • The limit on the number of pool threads that CICS can use at any one time.
  • If a transaction cannot get a pool thread, whether it should wait for one, or be abended.
  • What application plan or dynamic plan exit is used for the pool threads (see Plans, packages and dynamic plan exits).
  • At what point during a transaction's use of the thread DB2 accounting records are produced.
  • If there is a deadlock, whether changes made by the transaction using the thread are rolled back.

You can have only one DB2CONN definition installed in a CICS system at one time, and all the DB2ENTRY and DB2TRAN definitions that you install in the system are associated with the DB2CONN definition. If you discard a DB2CONN definition, all the DB2ENTRY and DB2TRAN definitions are discarded as well. You cannot discard a DB2CONN definition and install another one while CICS is connected to DB2.

Do not confuse the DB2CONN resource definition with the DB2CONN system initialization parameter, which specifies whether you want CICS to start the DB2 connection automatically during initialization.

You can start the CICS DB2 connection with only a DB2CONN definition installed; you do not need any DB2ENTRY and DB2TRAN definitions to make the connection. If you do this, there are no special threads for key transactions (entry threads). All transactions use general-purpose threads from the pool, and the most important transactions have to wait just as long as the least important transactions to get their individual connection into DB2. To ensure that your important transactions are prioritized, create DB2ENTRY and, if necessary, DB2TRAN definitions for them.

DB2ENTRY

You can set up many DB2ENTRY definitions to define different types of entry threads. The entry threads can be used by the transactions that you specify, to gain priority access (or specialized access) to DB2 resources. In effect, you are reserving a certain number of threads that can only be used by those transactions. You can also protect a number of each type of entry thread, which improves performance for heavily-used transactions.

In a DB2ENTRY definition, you can specify a particular transaction, or (by using a wildcard) a group of transactions, that are associated with the DB2ENTRY and can use the type of entry thread that it defines. When those transactions request a thread, the CICS DB2 attachment facility gives them that type of entry thread, if one is available. If you want other transactions to use the same type of entry thread, you can create a DB2TRAN definition for those transactions, which tells CICS that the transactions are associated with a particular DB2ENTRY.

You cannot discard a DB2ENTRY while transactions are using that type of entry thread. You must disable it first, to quiesce activity on the DB2ENTRY, and then discard it. If you discard a DB2ENTRY, the DB2TRANs associated with it are “orphaned”, and the transactions listed in them will use pool threads.

If you are using CECI, the command-level interpreter transaction, to test the syntax of CICS commands in an application program, be aware that in this situation, CICS uses the transaction ID CECI to check for matching DB2ENTRY definitions. If you have set up a DB2ENTRY for your application program and you want to replicate it when using CECI, set up a DB2ENTRY with the same properties for the CECI transaction.

DB2TRAN