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
Release : 20.0
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.