Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Categories z/TPF
Created by Guest
Created on Jun 24, 2022

Add High Speed Connector metrics as a CDC data flow for RTMC

HSC end point metrics are maintained in the group control block (e.g. number of application timeouts), and socket control block structures (e.g. total number of APIs, Total number of errors etc). HSC end point metrics should be added to RTMC as a CDC data flow to allow for monitoring, alerting, trending, and trouble shooting.

At a minimum we think the following metrics should be provided in these feed :

  • APIs per second per endpoint (based on change in cumulative count in scb_api_tot_ct) + total APIs per second for all endpoints in a group

  • Errors per second per endpoint (based on chnage in cumulative count in scb_err_tot_ct) + total errors per second for all endpoints in a group

  • Application timeouts per second (believe gcb_num_appl_timeout from the group control block is the correct metric)

  • Avg response time (mics) per endpoint for the last minute and for all APISs (scb_cur_wdw_api_resp and scb_cur_api_resp)

  • current number of active sessions (scb_asess)

  • current number of sockets in use (scb_inuse)

  • max number of sockets (scb_maxSocket)

  • starting sockets (scb_startSocket)

  • number of connects per second (from change in scb_num_connects)

  • number of failed connects per second (from change in scb_num_connects_fail)

In addition, it would be useful to send error information on the last conn fail if a new conn failure occurs since the last send of data was done. Useful error information for the latest conn failure would include:

  • Last conn fail API (scb_last_conn_error_api)

  • Last conn fail port (scb_last_conn_error_port)

  • Last conn fail SSL reason code (scb_last_conn_error_ssl_reason

  • Last conn fail time (scb_last conn_error_tod)

  • Last conn fail result (scb_last_conn_error_verify_result)

  • Last conn fail SSL error (scb_last_conn_error_ssl)

Idea priority Medium