By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,083 Members | 2,237 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,083 IT Pros & Developers. It's quick & easy.

IDTHTOIN Alternatives DB2 v7 z/OS

P: n/a
Our Mainframe DBA insists that the IDTHTOIN parameter be set to 600
so
that all idle threads timeout after 10 minutes. This is causing a
particular packaged application that expects to hold idle threads
open
for as long as it wants problems. From an application standpoint
there is not an acceptable workaround that would allow the
application
to create connections dynamically at this point.

Our Mainframe DBA has no alternatives and refuses to research the
situation for alternatives. We are on DB2 v7 z/OS. Can anyone
recommend any alternatives that would allow us to more granular
control of cancellation of idle threads? I can understand the need
of
the DBA to keep control over certain idle timeouts but it would be
very nice to be able to override this somehow for a particular
process
id or something. If anyone has any suggestions on how we might
implement a more granular control over Idle thread allowing certain
Idle threads to remain Idle as long as they want and other Idle
threads to be forced off after a certain time period I would
appreciate some suggestions.
Spencer
Nov 17 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Spencer wrote:
Our Mainframe DBA insists that the IDTHTOIN parameter be set to 600
so
that all idle threads timeout after 10 minutes. This is causing a
particular packaged application that expects to hold idle threads
open
for as long as it wants problems. From an application standpoint
there is not an acceptable workaround that would allow the
application
to create connections dynamically at this point.

Our Mainframe DBA has no alternatives and refuses to research the
situation for alternatives. We are on DB2 v7 z/OS. Can anyone
recommend any alternatives that would allow us to more granular
control of cancellation of idle threads? I can understand the need
of
the DBA to keep control over certain idle timeouts but it would be
very nice to be able to override this somehow for a particular
process
id or something. If anyone has any suggestions on how we might
implement a more granular control over Idle thread allowing certain
Idle threads to remain Idle as long as they want and other Idle
threads to be forced off after a certain time period I would
appreciate some suggestions.
Spencer
Have your DBA check the setting for CMTSTAT in DSNZPARM.
It should be set to INACTIVE (which is the default in DB2 v8 but not in v7).
This should allow the connection to go inactive but still "hang around".
The database access thread (DBAT) will be returned to the pool to be used by
another connection.
This should work for "well behaving" apps, i.e. apps that do commits now and
again.

HTH

--
Jeroen
Nov 18 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.