How do I implement support for DB2 subsystems that are members of a DB2 Data Sharing Group?
search cancel

How do I implement support for DB2 subsystems that are members of a DB2 Data Sharing Group?

book

Article ID: 52234

calendar_today

Updated On:

Products

RC Compare for DB2 for z/OS Bind Analyzer for DB2 for z/OS SQL-Ease for DB2 for z/OS SYSVIEW Performance Management Option for DB2 for z/OS Plan Analyzer for DB2 for z/OS Subsystem Analyzer for DB2 for z/OS Database Analyzer for DB2 for z/OS Fast Unload for DB2 for z/OS Fast Check for DB2 for z/OS Fast Index for DB2 for z/OS Rapid Reorg for DB2 for z/OS

Issue/Introduction

Description:

I want to be able to see all threads that are active in all members of a DB2 Data Sharing group on a single Active Threads list. What's the correct procedure for implementing support for DB2 Data Sharing in Insight?

The process involves updating the Insight Data Collector (DC) system parameters: DBSUB, DB2-LOCATION, DATASHARING and DC-GROUP; coding the correct location name in the APPLS parameter; code correct DBSUB, DB2LOC parameters in the EXEC PARM statement in the Insight DC started task JCL.

If members of the DS group are on different, i.e., remote Lpars, then one must also implement the RAF facility as documented in the Insight System Guide in Chapter 4.

This will allow Insight to connect to the remote Insight DC.

Solution:

To implement support for a DB2 Datasharing Group in Insight, the following must be done.
Assume one has two DB2 members in a DS group.
Group name is DSN0.
First member is DSN1; second member is DSN2.
Typical naming conventions would have three Insight parameter members in the SOURCE product library.
IDDCPRMS would be parameters applicable to all DCs.
APPLS would be the list of DB2 ssids being monitored.
DSN1SYSP would be parameters specific to DSN1 ssid.
DSN2SYSP would be parameter specific to DSN2 ssid.

  1. Implement the following Insight parameters in DSN1SYSP and DSN2SYSP:
    DSN1SYSP:
    ...
    DBSUB=DSN1 /* Identify DB2 DS member/ssid */
    DATASHARING=YES /* This turns on Insight's support for DS */
    DC-GROUP=DCGDSN0 /* Implements an Insight Data Collector Group in the SYSPLEX */
    DB2-LOCATION=IDB2LOCDSN0 /* 16 characters used to further identify DB2 ssid */
    ...
    DSN2SYSP:
    ...
    DBSUB=DSN2
    DATASHARING=YES
    DC-GROUP=DCGDSN0
    DB2-LOCATION=IDB2LOCDSN0
    ...

  2. Implement the following in the APPLS member:

    APPLS= (
    IDB2LOCDSN0,DSN1,NOTRAF /* DB2-LOCATION,DBSUB,RAF Vtam Applid */
    IDB2LOCDSN0,DSN2,NOTRAF
    )

  3. The Insight DC started task JCL proc would code:
    ...
    //IDB2DC EXEC PGM ....
    // PARM=('/DBSUB=DSN1,DBLOC=IDB2LOCDSN0,...')

    The Insight Data Collector Group (DC-GROUP) is similar to DB2's Data Sharing Group. The Insight DC Group name must be unique within the sysplex, so do NOT use the DB2 DS group name.
    And a unique DC-GROUP must be coded for each DS group within the Sysplex that is being monitored by Insight. Can be maximum of any 8 characters in length.
    If DATASHARING=YES, and no DC-GROUP name is coded, then the default used is XDBGDCxx, where xx is the release. For r12 it would be XDBGDC12.

Note that DB2-LOCATION is the same for both DB2 ssids being monitored. This is required to implement support for DS in Insight. All members being monitored by Insight must use the same location name. Can be a maximum of any 16 characters in length.

The same location string must be used for DB2-LOCATION, the DB2-LOCATION parameter in the APPLS member, and the DB2LOC parameter on the EXEC PARM of the Insight DC JCL.

This is documented in the Insight System Guide, Chapter 3.

If one or more members of the DS group are on remote Lpars, then you must implement the Remote Access Facility. Full details are in the Insight System Guide, Chapter 4. It is not covered here.

Environment

Release:
Component: IDB2