These administrative tasks consist
primarily of configuring
the objects, or resources, through which applications connect with
a backend, and tuning those resources to handle the volume of connection
requests.
Results
If your z/OS
® application
connects to a z/OS version of DB2 that
serves multiple platform versions of
WebSphere Application Server, the z/OS application
might incur an EC3 dump during run time. To resolve the problem, set
the CMTSTAT parameter to INACTIVE when you plan to run distributed
workloads.
Avoid trouble: For DB2 Version
7.0 on a z/OS system, the default value for CMTSTAT is
ACTIVE. For DB2
Version 8.0 on
a z/OS system, the default setting is set to INACTIVE.
gotcha
Distributed
workloads are generally large. The CMTSTAT=INACTIVE setting triggers DB2 to
free up resources to counteract the drain that can be caused by large
workloads. DB2 will deactivate threads after the threads
successfully commit or roll back database tasks and release cursors.
If
you set CMTSTAT=INACTIVE, you might need to adjust the CONDBAT and
MAXDBAT parameters as well. Try the following combination of values
to maximize the performance of DB2 and
minimize suspended connection requests:
- Set MAXDBAT to a low
number, like 100, which DB2 can
support as active threads. MAXDBAT indicates the maximum number of
threads that can remain active at the same time and continue running
tasks in DB2.
- Set CONDBAT to a high number, like
5000. CONDBAT indicates the
maximum number of connection request threads that your DB2 server
can receive. When you set CMTSTAT to INACTIVE, DB2 will
deactivate many threads after fulfilling the initial connection requests.
When the number of threads that require further processing reaches
the MAXDBAT setting, DB2 can queue other threads until
it can handle them.