CONDBAT under DB2 Z/os V11 (CM)

Art McEwen

CONDBAT under DB2 Z/os V11 (CM)
Several versions ago there was a zparm timeout for how long a DDF thread stayed in the "inactive" pool. That went away with V9 maybe?

We've got a case where we're running into the CONDBAT limit but our MAXDBAT high water mark (as reported by CA-Insight) is still very low. My question is what gets a thread off the CONDBAT list or makes an existing thread on that list eligible for reuse as opposed to creating a new entry. Or has IBM really redefined the meaning of this parm?

The only diagnostic tool to see where these threads are coming from is IFCID 003 remote connections but that's just a gross number of connection attempts not a thread status.


Art McEwen

Sr DBA, Database & Mainframe Support
Health Solutions Delivery Br.
Health Services Cluster
4th flr, 49 Place d'Armes
Kingston ON K7L 5J3

[login to unmask email]<mailto:[login to unmask email]>

Office 613-548-6622
Cell 613-539-3903

Ray Lopez

RE: CONDBAT under DB2 Z/os V11 (CM)
(in response to Art McEwen)

Hi Art,   we encounter the same problem every once in awhile.  I haven't gotten much of a solution to this but here is what we do. 
See DSNL200I:
This reports information about connections with remote locations.

LOCATION                                       PRDID    T ATT   CONNS
::                                JCC04140 S         10
::                                JCC04120 S          0
::                                JCC03690 S          2
::                                JCC04140 S         15

You can tell who is using up the connections.  The offenders will get up to  80 CONNS or so.

Now you can contact the offending server people and tell them to recycle their server.   Or you have to recycle DDF to free the connections, but that punishes all DDF users and is usually unacceptable.  I have not found a command to free up just the connections.  That has to be done from the remote side.   It would be nice if we had such a thing.

What we found is that Connections are not using much in resources.  You can bump this limit way up. Way above the MAXDBAT threshold.  We have a monitoring job that accumulates the CONN counts off the -DISP LOC(*) display.   That warns us when we have a problem and we can contact the offending server.  But we have the actual CONDBAT so high, it does not impact things.

For example, we have MAXDBAT at 250, but CONDBAT at 1000.   Our monitoring threshold for CONDBAT is 250, but it is not a hard stop.

Apparently, occasionally, some remote server will open and hold lots of connections, even when not doing much work.  We have a couple apps that are notorious for this, one is a Websphere app, the other a Web app.

I would like to stay in touch with you in case we can find a better solution to this.  I hope you get some knowledgeable responses to this post.   [login to unmask email]


Art McEwen

RE: CONDBAT under DB2 Z/os V11 (CM)
(in response to Ray Lopez)

Thanks Ray,    We identified the troublesome app (websphere) via netstat command but your display loc is a better idea.




J&#248;rn Thyssen

RE: CONDBAT under DB2 Z/os V11 (CM)
(in response to Art McEwen)

Hi Art,

You can use Db2 profiles to limit connections per application, IP address or other criteria. This can be used to avoid a single misbehaving application eating up all the allowed connections. 


Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: 

Views are personal.