Background:

z/OS Data Gatherer is the strategic IBM performance measurement tool in a z/OS host environment. Considering the complexity of Data Gatherer REST services, they should be deployed on separate z/OSMF server instances so that they do not impact or get impacted by other z/OSMF plugins.

Objective:

This article outlines the advanced configuration steps for establishing communication between a primary z/OSMF and a z/OS Data Gatherer server. It focuses on the use case of z/OSMF monthly feedback collection (APAR PH56716), with sample RACF commands. If your installation uses an external security manager other than RACF, you must use equivalent commands for your environment.

Configuration Steps:

The primary z/OSMF server, which hosts the feedback collection service, initiates HTTPS requests to the z/OS Data Gatherer server, where the Data Gatherer Monitor II REST Services are hosted. The HTTPS connection is established by the started task ID of the primary z/OSMF. Therefore, the started task ID of the primary z/OSMF server needs appropriate authorization to access the z/OS Data Gatherer services. Additionally, configuring digital certificates is necessary.

If you cannot set up the z/OS Data Gatherer server by reusing the existing security setup of the primary z/OSMF server, please consider the following scenarios and use the corresponding sample commands to establish communication between the primary z/OSMF server (Server A) and the z/OS Data Gatherer server (Server B).

• Scenario #1:  Both servers are located within the same sysplex.

• • Step #1:  Connect the Certificate Authorities (CAs) of both servers to each other's keyrings, ensuring mutual trust in the SSL connection between the two servers.

RACDCERT ID(B's STC id) CONNECT(LABEL('STCA_CA_of_ssl_cert') RING(B's keyring) CERTAUTH)

RACDCERT ID(A's STC id) CONNECT(LABEL('STCB_CA_of_ssl_cert') RING(A's keyring) CERTAUTH)

• • Step #2:  Connect the STC ID of server A to the z/OSMF group of server B.

CONNECT (A's STC id) GROUP(zosmf_group_of_serverB)

• Scenario #2:  The two servers are located on different sysplexes.

• • Step #1:  Include the Certificate Authority (CA) and the digital certificate of Server A into Server B.

• • • Export the digital certificate and its CA of server A.

RACDCERT ID( A's STC id ) EXPORT(LABEL('STCA_ssl_cert' )) DSN('ZOSMF.SEVERA.CERT.CRT') FORMAT(CERTDER)

RACDCERT CERTAUTH EXPORT(LABEL('STCA_CA_of_ssl_cert' ) ) DSN('ZOSMF.SEVERA.CA.CRT') FORMAT(CERTDER)

• • • Upload the exported certificates to server B in binary mode.

• • • Prior to adding the digital certificate into server B, you must identify the user ID. This user ID can either match the STC ID of server A or be a new one. The user ID should be associated with the z/OSMF user group of server B.

ADDUSER user_id DFLTGRP(z/OSMF group of server B) OMVS(AUTOUID HOME(/usr's home) PROGRAM(/bin/sh)) NAME('id of server A') NOPASSWORD

• • • Add the exported certificates into server B.

RACDCERT ID( user_id )  ADD('ZOSMF.SERVERA.CERT.CRT') TRUST WITHLABEL('STCA_ssl_cert') 
RACDCERT CERTAUTH ADD('ZOSMF.SERVERA.CA.CRT') TRUST WITHLABEL('STCA_CA_of_ssl_cert')


• • • Add the CA of server A to the keyring of server B

RACDCERT ID( B's STC id ) CONNECT (LABEL('STCA_CA_of_ssl_cert')  RING(B's keyring) CERTAUTH)

• • Step #2:  Add the CA of server B to server A.

• • • Export the CA of server B.

RACDCERT CERTAUTH EXPORT(LABEL('STCB_CA_of_ssl_cert' ) ) DSN('ZOSMF.SERVERB.CA.CRT') FORMAT(CERTDER)

• • • Upload the above certificate into server A in binary mode.

• • • Add it to server A.

RACDCERT CERTAUTH ADD('ZOSMF.SERVERB.CA.CRT') TRUST WITHLABEL('STCB_CA_of_ssl_cert')

• • • Add the CA of server A to the keyring of server B.

RACDCERT ID( A's STC id ) CONNECT (LABEL('STCB_CA_of_ssl_cert')  RING(A's keyring) CERTAUTH)

Disclaimer:

1. This document intends to represent the views of the author rather than IBM.

2. The recommended solutions are not guaranteed, please contact the author liqiliqi@cn.ibm.com instead of IBM service for any questions.