Setting up the Distributed Data Server for z/OS

Applications that want to access sysplex-wide performance data, can retrieve their input from a single data server on one system in the sysplex, which gathers the data distributed on all systems in the sysplex. Therefore, this is called the Distributed Data Server (DDS).

The DDS offers an HTTP API which can access short-term data from the Monitor III as well as long-term data from the Postprocessor. An application program can send an HTTP request for selected performance data to the DDS.

Note: Equivalent to the DDS component GPMSERVE, which gathers performance data from z/OS® systems in a sysplex, RMF XP provides a second DDS component called GPM4CIM, which you can use to gather performance data from AIX® and Linux® operating systems. For general and setup information about RMF XP refer to Cross platform monitoring with RMF XP. z/OS Resource Measurement Facility Programmer's Guide provides information about how to exploit the HTTP API of GPM4CIM if you want to submit requests for AIX and Linux performance data. The remaining information in this topic is about GPMSERVE for z/OS only.

Exploiters of Monitor III performance data provided by the DDS are, among others, z/OS Capacity Provisioning, z/OSMF, or RMF PM. If you want to monitor systems in a sysplex, you must set up a Distributed Data Server (DDS) host session on the system in the sysplex with the highest RMF release. If you want to monitor several sysplexes, each one needs to have an active DDS.

To start the DDS, RMF provides the cataloged procedure stored in SYS1.PROCLIB(GPMSERVE): 

//GPMSERVE PROC ROOT='/usr/lpp/gpm',
//   JAVA='/usr/lpp/java/J17.0_64',
//   MEMBER=00,
//   OUTCLS='*',
//   JAVAVER='17',
//   JAVALGLV='',
//   REGSIZE='0M',
//   LEPARM=''
...
//PMJAVA  EXEC PGM=JVMLDM&JAVAVER,REGION=&REGSIZE,
//   PARM='&LEPARM/&JAVALGLV'
...
//GPMPPJCL DD   DISP=SHR,DSN=SYS1.SERBPWSV(GPMPPJCL)
...
The memory requirements for the DDS are dependent on several factors:
  • Number of Cache Slots
  • Number of Resources in the Sysplex
  • Number of DDS clients and so on.
Note: DDS provides support for HTTP compression and zEnterprise Data Compression (zEDC). For more information about zEDC, refer to the IBM Semeru Runtime Certified Edition for z/OS documentation.

Prerequisites for exploiting the Monitor III HTTP API

On those systems where you want to monitor short-term Monitor III data, you need to start the Monitor III gatherer with identical MINTIME and SYNC options (see Description of Monitor III data gatherer options in z/OS Data Gatherer User's Guide).

Also make sure, that the following prerequisites are met on your z/OS host:

  • Unix System Services must be configured in full function mode.
  • TCP/IP under Unix System Services must be configured and fully initialized.

Prerequisites for exploiting the Postprocessor HTTP API

To get access to Postprocessor data provided by the DDS, the GPMSERVE started task points to a Postprocessor job called GPMPPJCL. A JCL template for this job is stored in SYS1.SERBPWSV(GPMPPJCL).

You must adapt or replace the GPMPPJCL member to suit your installation, ensuring that the DDS is able to run RMF Postprocessor jobs. If you do not want to request Postprocessor data with the DDS, you can omit the GPMPPJCL DD card from the GPMSERVE started task.

By default, the RMF Postprocessor retrieves data from all available intervals in the SMF buffer. You can modify the GPMPPJCL template to retrieve only SMF data from the most current interval by adding a job step similar to the following GETSMF sample job step:

//GETSMF EXEC PGM=ERBAPPL,PARM='?/*/70:78'
//SMFDATA DD DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(CYL,(2,2))
//ERBLIST DD SYSOUT=*
The example job step retrieves data from SMF record types 70 through 78 for the most current interval, indicated by the question mark used for the start time. If you use ERBAPPL in your GPMPPJCL job, you must add an MFPINPUT DD card to the Postprocessor job step RMFPP in GPMPPJCL with a backward reference to the SMFDATA DD card of the GETSMF job step, for example: 
//MFPINPUT DD DISP=(OLD,PASS),DSN=*.GETSMF.SMFDATA

GPMPPJCL template

/*JOBPARM  SYSAFF=*
//RMFPP    EXEC PGM=ERBRMFPP
//MFPMSGDS DD   SYSOUT=*
//XPRPTS   DD   SYSOUT=*
//XPXSRPTS DD   SYSOUT=*
//XPOVWRPT DD   SYSOUT=*
//SYSOUT   DD   SYSOUT=*
//SYSIN    DD   *

Note that the Postprocessor API functionality is only available with JES2 installed. Omit the GPMPPJCL ddname in a JES3 environment.

The complete DDS HTTP API is described in z/OS Resource Measurement Facility Programmer's Guide.

Prerequisites for exploiting the SMF data set support of the Postprocessor HTTP API

To get access to preallocated SMF data from data sets or log streams with the Postprocessor HTTP API provided by the DDS, the GPMSERVE started task must point to a Postprocessor job with its GPMPPJCL DD card. The Postprocessor JCL provided here should be derived from the JCL template stored in SYS1.SERBPWSV(GPMPPJV2).

You must adapt this GPMPPJV2 member to suit your installation (like with GPMPPJCL) and additionally, you must provide a user ID for the USER parameter of the JOB card. The user ID used at this place depends on the setting of the HTTP_NOAUTH option in your GPMSERVE started task.
  • Distributed Data Server running with HTTP_NOAUTH(*) or HTTP_NOAUTH(ip-addr):

    Provide a universal user ID, GPMUID, with the USER parameter on the JOB statement (USER=GPMUID); here, universal means that the user ID can be used by all exploiters of the DDS (by all authorized exploiters in the case of HTTP_NOAUTH(ip-addr) to access the SMF data sets. The user ID GPMUID may be empty, in which case the Postprocessor job runs under the authority of the GPMSERVE started task user ID.

  • Distributed Data Server running with HTTP_NOAUTH():

    Leave the //*UID line in the GPMPPJV2 template unchanged in this case. The Distributed Data Server takes the user ID which is used for authorization to the DDS to substitute the user ID in the USER parameter.

The GPMSERVE user ID needs permission to submit jobs on behalf of GPMUID and it needs UPDATE access to the job output on the JES spool. The following example shows RACF® commands which allow these actions: 
RDEFINE SURROGAT GPMUID.SUBMIT UACC(NONE) OWNER(GPMUID)
PERMIT GPMUID.SUBMIT CLASS(SURROGAT) ID(GPMSERVE) ACCESS(READ)
SETROPTS RACLIST(SURROGAT) REFRESH

RDEFINE JESSPOOL nodename.GPMUID.GPMSERVE.** UACC(NONE) OWNER(GPMUID)
PERMIT nodename.GPMUID.GPMSERVE.** CLASS(JESSPOOL) ID(GPMSERVE) ACCESS(UPDATE)
SETROPTS RACLIST(JESSPOOL) REFRESH
In order to use the job deletion functionality implemented with the joboutdel request parameter, a RACF profile in the JESJOBS class has to be defined like in the following example for the user GPMUID and the Postprocessor job GPMDDSPP started by GPMSERVE: 
RDEFINE JESJOBS PURGE.nodename.GPMUID.GPMDDSPP UACC(NONE)
PERMIT PURGE.nodename.GPMUID.GPMDDSPP CLASS(JESJOBS) ID(GPMUID) ACC(ALTER)