SCM command not showing the DB2 Health Status

Article Id: 196480
Status: Published
Updated On: 26-08-2020 06:25
Products:
CA SYSVIEW Performance Management , NXBRIDGE - SYSYVIEW/ENDEVOR
Issue/Introduction:

SCM command not showing the DB2 Health Status

Besides the text below, I am attaching the GSSA sysout and SCM command screenshot.

SRV103   INCLUDE DB2              // Include DB2 support
SRV098 Member DB2      found in SYS2.CA.CCS.CAW0OPTN
SRV085 Member DB2      last updated by userid=BR12273  on 2020-08-03 2020.216 at 10:13:52
SRV340 Now processing PARMLIB member DB2
SRV103 ***********************************************************************
SRV103 ***  Initialization Parameters for DB2 support.  Note that you      ***
SRV103 ***  must provide a SRVDB2P load module and bind it to DB2          ***
SRV103 ***  before dynamic SQL can be executed.  See SAMPJCL member        ***
SRV103 ***  YS28DB2P for the source code and JCL required to generate      ***
SRV103 ***  the required load module (SRVDB2P).                            ***
SRV103 ***********************************************************************
SRV103
SRV103   ADDRESS DSNALI   DSNALI   TYPE   8 // Required for DB2() function
SRV103   ADDRESS DSNHLI2  DSNHLI2  TYPE 255 // Required for DB2() function
SRV103   ADDRESS SRVDB2P  SRVDB2P  TYPE 255 // Required for DB2() function
SRV103   DB2PLAN GSSPLAN                    // Default
SRV103   SSID DB2  DSB1                     // Default
SRV341 Resuming processing PARMLIB member RUNPARM

 

Environment:

Release : 16.0

Component : SYSVIEW

Resolution:

Please update the SCM Parmlib entries for DB2 by uncommenting them and updating the entry with the correct Subsystem.

Once you have completed this you will need to recycle the GSS STC to pick up the changes.

Additional Information:

When SYSVIEW inside of GSS initializes, it will issue the SYSVIEW command:
 
LIBVIEW PARMLIB SCM
 
to determine the entries that are to be built for the SCM display.
 
The doc that you sent in shows:
 
 10:17:36 SRV001 00000009 SCMREADPDS       (00056) Type      Member   Alias    Cache DatasetName
 10:17:36 SRV001 00000009 SCMREADPDS       (00056) PARMLIB   SCM      *        NO    SYS2.CA.SYSVIEW.CNM4BPRM
 10:17:36 SRV001 00000009 SCMREADPDS       (00056) UserId    VV.MM     Size  Init   Mod  CreateDate      ChangeDateTime
 10:17:36 SRV001 00000009 SCMREADPDS       (00056) SYSV160   01.00      486   486     0  2019/05/03      12:36:00 2019/05/03
 
So, it is reading the library/member:
SYS2.CA.SYSVIEW.CNM4BPRM(SCM)
 
It then will list out the IMODs that are to be run by the GSS STC by Type / Name / Interval etc.
  
The GSS STC Log does not show an entry for DB2.
 
By default the call to execute the DB2 IMODs is commented out.
 
*        System..   Type....   Subsystem
* DEFINE *          DB2        DBV6     
*        INTERVAL   60                  
*        IMOD       *                   
*        PARMS                          
*        DETAILIMOD SCM_IDB2   DBV6     
*        DETAILIMOD SCM_IDB2   *        
 
Please update the SCM Parmlib entries for DB2 by uncommenting them and updating the entry with the correct Subsystem.
 
Once you have completed this you will need to recycle the GSS STC to pick up the changes.