When DSNL077I tells us IN-USE DBAT is exceeding 85% of MAXDBAT then ALSO issue DISPLAY THREAD

DB2 has recently introduced message DSNL077I which tells us when IN-USE DBATS begin to exceed 85% of system parameter MAXDBAT.

And the corresponding message of DSNL078I tells us when IN-USE DBATS falls below 75% of MAXDBAT

https://www.ibm.com/docs/en/db2-for-zos/12?topic=messages-dsnl077i

https://www.ibm.com/docs/en/db2-for-zos/12?topic=messages-dsnl078i

This new functionality was introduced in 2020, as per DB2 what’s new documentation

https://www.ibm.com/docs/en/db2-for-zos/12?topic=12-2020-new-function-apars

The documentation reminds us that this new functionality came via APAR PH30222

https://www.ibm.com/support/pages/apar/PH30222

I now realize that it is VERY interesting to know when IN-USE DBAT is getting close to MAXDBAT. This is a nice new message. Thank you IBM and DB2!!! Very cool.

But it is now obvious (especially because I have seen DSNL077I in real life) that it would extra helpful if DB2 also displayed the output of

DISPLAY THREAD(*) TYPE(*) LOCATION(*) LIMIT(*) DETAIL

Why is this DISPLAY THREAD output interesting? Because I want to see the status of all these threads at the moment in time when we begin to exceed 85% of MAXDBAT. It would help me understand what is going with the DBAT at this moment of time!!!

Here is the background and my scenario of how I experienced DSNL077I:

We started to have some application usage when we IN-USE DBAT actually reached MAXDBAT (long story). I later reviewed the MSTR JESMSGLG and saw the helpful DSNL077I which confirmed the time when my application issue began. I later reviewed my account trace history, and I could not find any threads starting and ending around this moment in time. It was a mystery why so many DBAT were IN-USE. No accounting trace! But IN-USE DBAT was over 85% of MAXDBAT. How?

Later I was online during the next DNSL077I and at that time, I managed to manually issue the DISPLAY THREAD command. The DISPLAY THREAD output (DSNV402I) shows a few lines per thread and I saw that all of IN-USE DBAT were actually in a funny flux state with DISCN-NC, STATUS of RA, and ID of 028.DBAA

https://www.ibm.com/docs/en/db2-for-zos/12?topic=messages-dsnv402i

• Basically, I learned all my DBAT were were recently disconnected and were in the process of being reassigned to a new connection, but Db2 was going to my external security product to authorize the userid. And this was taking a surprising long time to respond (the root of my real problem). The DBAT was not actually assigned to the next connection yet. Technically, the DBAT was not disconnected at that moment. So technically the DBAT was in-use. But it was not in-use by a userid (yet)

• Anyways, I am NOW using my system monitor tool to watch for DSNL077I message in my MSTR JESMSGLG (or it watches the “system log”). And my system monitor will issue the DISPLAY THREAD.

This scenario that we encountered was originally raised as a CASE with IBM Support in TS015889850. In the case, IBM Support saw my idea that DISPLAY THREAD be generated at the moment of time of DSNL077I. They seemed to agree and suggested that I open a RFE (hence this RFE)

YES, I know a system monitor tool could issue the DISPLAY THREAD command, BUT, I think it would be useful if DB2 did the DISPLAY THREAD automatically when the DSNL077I is produced. That would be useful for ALL users of Db2 who encounter DSNL077I in the future (not just me). Then they would see the valuable info about each DBAT. They would know more than 85% are in-use. The would get the answer to the obvious question about what are these DBAT doing at this moment!!!

So my “idea” or “RFE” for DB2 is two suggestions.

• High importance– when DSNL077I is displayed then also show output of

• DISPLAY THREAD(*) TYPE(*) LOCATION(*) LIMIT(*) DETAIL

• Nice to have – The messages DSNL077I (and DSNL078I) should obviously show the MAXDBAT value in the message. >> You know it! Just tell me now in the message! Don’t make me look it up!