DDS options

The preparation of the z/OS component of the DDS host session (GPMSERVE) as server address space for possible exploiters requires the customization of options in a parmlib member that is needed for the GPMSERVE procedure to start the Distributed Data Server.

RMF provides a default parmlib member GPMSRV00, which you may tailor according to your needs. To display the active DDS options, you can use the following command:

MODIFY GPMSERVE,OPTIONS

Note: A subset of the DDS options is also used by the GPM4CIM component of RMF XP, for example, CACHESLOTS, or HTTP_NOAUTH. For information on the RMF XP setup refer to How to set up RMF XP.

Here is the content of GPMSRV00:

/*********************************************************************/
/*                                                                   */
/* NAME:        GPMSRV00                                             */
/*                                                                   */
/* DESCRIPTION: PARMLIB MEMBER FOR THE RMF DISTRIBUTED DATA SERVER   */
/*              HOST ADDRESS SPACE (GPMSERVE)                        */
/*                                                                   */
/*********************************************************************/
CACHESLOTS(4)                   /* Number of timestamps in CACHE     */
DEBUG_LEVEL(0)                  /* No  informational messages        */
SERVERHOST(*)                   /* Don't bind to specific IP-Address */
MAXSESSIONS_INET(5)             /* MaxNo RMF PM clients              */
SESSION_PORT(8801)              /* TCP/IP port number RMF PM         */
TIMEOUT(0)                      /* No timeout                        */
MAXSESSIONS_HTTP(20)            /* MaxNo of concurrent HTTP requests */
HTTP_PORT(8803)                 /* Port number for HTTP requests     */
HTTP_ALLOW(*)                   /* Mask for hosts that are allowed   */
HTTP_NOAUTH()                   /* No server can access without auth.*/
EXCLUDE_REPORTS()               /* Reports to be deactivated         */
HTTPS(ATTLS)                    /* AT-TLS setup required             */
CLIENT_CERT(NONE)               /* Client certificates are ignored   */

CACHESLOTS

Number of CACHE entries (one for each MINTIME). The valid scope is 3 through 32.

DEBUG_LEVEL

Amount of messages that is sent to the SYSPRINT data set. The valid scope is 0 through 3. DEBUG_LEVEL(0) suppresses all informational messages.

SERVERHOST

TCP/IP address (or hostname) to which the server binds when it opens any listener sockets. You should only use this option, if a host has several TCP/IP addresses (different network adapters) and you want the DDS server to bind its services to one specific TCP/IP address. Make sure, that the value you specify is the valid TCP/IP address (or hostname) of the host where the DDS server runs. On z/OS, you may use the TSO HOMETEST command to find out the valid TCP/IP addresses.

Example: SERVERHOST(9.164.123.244)

Default: SERVERHOST(*) (any TCP/IP address).

MAXSESSIONS_INET

Maximum number of permitted concurrent RMF PM clients. Additional clients are rejected. The maximum allowed value is 100.

SESSION_PORT

TCP/IP port number for RMF PM clients. It must correspond to the port number, that the clients specify in the SYSPLEX settings.

TIMEOUT

Number of seconds of inactivity, before DDS assumes a timeout condition on the TCP/IP connections for RMF PM clients.

MAXSESSIONS_HTTP

Maximum number of permitted concurrent HTTP server threads. The maximum allowed value is 100.

HTTP_PORT

TCP/IP port number for HTTP requests.

HTTP_ALLOW

Host names or TCP/IP addresses that can use the HTTP interface. Wildcards * and ? are allowed. You may specify more than one HTTP_ALLOW statement.

Examples:

HTTP_ALLOW(*.ibm.com)
HTTP_ALLOW(9.164.*.*)
HTTP_ALLOW(sys?.boeblingen.de.ibm.com)

Default: HTTP_ALLOW(*)

Note: If your installation uses a proxy server for http access, you have to specify the hostname of the proxy server to allow access from users which use this proxy server.

HTTP_NOAUTH

Host names or TCP/IP addresses that can use the HTTP interface without authentication (user ID/password). Wildcards * and ? are allowed. You may specify more than one HTTP_NOAUTH statement.

Example: HTTP_NOAUTH(sysa.boeblingen.ibm.com)

Default: HTTP_NOAUTH()

Note:

The DDS supports PassTickets (see Configuring PassTicket support for the Distributed Data Server). If you run a CIM server in your z/OS environment, you can use PassTickets to grant this server access to the DDS. Otherwise, to grant CIM clients access to performance data, you must authorize the CIM server host via HTTP_NOAUTH, since the corresponding CIM RMF monitoring providers use the DDS HTTP API.
If your installation uses a proxy server for http access, you have to specify the hostname of the proxy server to allow access from users who use this proxy server.

EXCLUDE_REPORTS

List of Monitor III reports to be deactivated. All reports that are contained in this list will not be provided by the DDS.

You can mix single system and sysplex reports. The listed reports must be separated by a comma. You may specify more than one EXCLUDE_REPORTS statement.

Examples:

EXCLUDE_REPORTS(CFOVER,CFSYS) 
EXCLUDE_REPORTS(ZFSOVW,ZFSFS,ZFSKN)

Default: EXCLUDE_REPORTS()

Note: Deactivating reports has impacts on DDS exploiters:

All metrics based on the deactivated reports will not be provided by the DDS.
z/OS Capacity Provisioning connects to the DDS via the CIM server to obtain performance data from the CPC, SYSINFO, and SYSSUM reports. Therefore, never specify CPC, SYSINFO, or SYSSUM on EXCLUDE_REPORTS() when running Capacity Provisioning.

HTTPS

If ATTLS is specified, the DDS requires that the incoming HTTP connection is secured by an AT-TLS setup. If the incoming connection is not secured by an AT-TLS setup, the connection is refused. See Setting up the Distributed Data Server for z/OS for information about how to set up secure communication for the DDS.

If NO is specified, no further checks are done by the DDS. In this case, communication with the DDS can either be via HTTP or via HTTPS secured by AT-TLS.

Example: HTTPS(ATTLS)

Default: HTTPS(ATTLS)

CLIENT_CERT

If ACCEPT is specified, the DDS will accept incoming HTTP connections and will take the user ID from an AT-TLS provided client certificate to check the authorization against the ERBSDS.MON3DATA FACILITY class profile instead of using user ID/password authentication. If the incoming HTTP connection does not supply a client certificate that is associated with a user ID, user ID/password authentication is performed. See Setting up the Distributed Data Server for z/OS for information about how to set up secure communication for the DDS.

If NONE is specified, no further checks are done.

Example: CLIENT_CERT(ACCEPT)

Default: CLIENT_CERT(NONE)