You use resource definition online (RDO) to define the CICS® DB2® connection.
If you are migrating from an earlier release of CICS and have not
used RDO before, read Migrating from a CICS release that used RCT definitions for CICS DB2
resources. If your CICS system
is connected to DB2 Version 6 or later, the MAXOPENTCBS system initialization
parameter also influences the CICS DB2 connection -- for more
information, see The MAXOPENTCBS system initialization parameter and TCBLIMIT.
As we have read in Overview: How CICS connects to DB2, the CICS DB2 connection
consists of an overall connection between CICS and DB2, and individual
connections known as threads. You can define the attributes of the
overall connection, and the attributes of the different types of thread.
If you have specially defined entry threads for key transactions,
you can tell the CICS DB2 attachment facility which CICS transactions
can use those threads. Defining the CICS DB2 connection involves three
different objects: DB2CONN (the DB2 connection definition), DB2ENTRY
(the DB2 entry definition), and DB2TRAN (the DB2 transaction definition).
The scope of each object is as follows:
- DB2CONN
- DB2CONN is the main definition for the CICS DB2 connection.
You need to install a DB2CONN before you can start the CICS DB2 connection.
In the DB2CONN definition, you:
- Define the attributes of the overall CICS DB2 connection, which
are:
- the DB2 subsystem that CICS connects to, 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
- how error messages are communicated to CICS, and what transactions
should do if their thread fails
- where messages and statistics are sent
- Define the attributes of command threads (the special threads
used by the DSNC transaction for issuing DB2 commands), which are:
- 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,
the general-purpose CICS DB2 attachment facility ID)
- Define the attributes of pool threads (the general-purpose threads
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),
which are:
- 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.
You can
start the CICS DB2 connection with only a DB2CONN 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 simply tells CICS that the transactions are associated
with a particular DB2ENTRY.
In each DB2ENTRY definition, you:
- Specify a transaction, or (by using a wildcard in the name) a
group of transactions, that can use this type of entry thread
- Define the attributes of this type of entry thread, which are:
- what type of authorization ID DB2 checks when this type of entry
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 this type of entry thread that CICS
can use at any one time
- the number of this type of entry thread that are protected for
a period of time while they are not being used
- if a transaction associated with the DB2ENTRY cannot get this
type of entry thread, whether it should wait for this type of entry
thread, overflow to use a pool thread, or be abended
- what application plan or dynamic plan exit is used for this type
of entry thread (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 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
- You can use DB2TRAN definitions to associate additional transactions
with a particular DB2ENTRY -- the transactions will then use
that type of entry thread. Only one DB2TRAN definition can be installed
for a specific transaction. In each DB2TRAN definition, you simply:
- Specify the name of a DB2ENTRY
- Specify a transaction, or (by using a wildcard in the name) a
group of transactions, that are associated with the particular DB2ENTRY
and can use this type of entry thread
When those transactions request a thread, the CICS DB2 attachment
facility sees that they are associated with the particular DB2ENTRY,
and treats them like the transaction or transactions named on the
DB2ENTRY definition itself.
You
can define and install DB2CONN, DB2ENTRY and DB2TRAN objects using
RDO. The objects can also be defined in batch using DFHCSDUP. CICSplex
SM uses EXEC CICS CREATE to install these objects. For detailed information
about how to define each of these objects, see the CICS Resource Definition Guide.
Defining DB2CONN
Defining DB2ENTRY
Defining DB2TRAN
[[ Contents Previous Page | Next Page Index ]]