IDB2 diagnostics for Excessive Trace Data Lost DSNW133I DB2MSTR message

Products

• SYSVIEW Performance Management Option for DB2 for z/OS

Issue/Introduction

What action can be performed for Sysview for Db2 (IDB2) to provide more detail when the DB2MSTR address generates a massive amount of the following messages, and the IDB2 Data Collector Task is running at the prescribed dispatching priority? 

DSNW133I  TRACE DATA LOST, OP1  NOT ACCESSIBLE RC=08
DSNW123I  TRACE RECORDING HAS BEEN RESUMED ON OP1   
DSNW133I  TRACE DATA LOST, OP1  NOT ACCESSIBLE RC=08
DSNW123I  TRACE RECORDING HAS BEEN RESUMED ON OP1   
DSNW133I  TRACE DATA LOST, OP1  NOT ACCESSIBLE RC=08
DSNW123I  TRACE RECORDING HAS BEEN RESUMED ON OP1   

 

Environment

Release : 20.0

Resolution

If possible, issue IDB2 IFI and DCCPU online commands when this type of OPx problem occurs to obtain more information on possible cause. 

Also, if this type of condition becomes more prevalent the following slip can be set to provide a dump for more in-depth analysis: 

SLIP SET,A=SVCD,J=mstr,MSGID=DSNW133I,JL=(idb2dc),END

Note: In the SLIP trap, "J=mstr" should be replaced with the name of the DB2 MSTR address space, and "JL=(idb2dc)" replaced with the IDB2 Data Collector jobname.