Skip to Main Content
IBM Z Hardware and Operating Systems Ideas Portal


This is the public portal for all IBM Z Hardware and Operating System related offerings. 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
Workspace z/OS
Categories BCP_IOS
Created by Guest
Created on Feb 3, 2021

Reduce CPU consumption of IOS HyperSwap API address space for a large number of addresses

When executing a reload of the GDPS GEOPARM the IOSHSAPI ( IOS HyperSwap API address space ) consumes a lot of CPU in a short period of time when there is a high number of addresses under GDPS, causing some customer applications to slowdown and having a service impact.
This happens even when the changes in the I/O definitions of the customer affect a very few addresses since all the addresses have to be 'refreshed'.
According to the info provided in the case:
Loading a HyperSwap configuration can be CPU intensive, especially when so many devices exist in the configuration. In addition to building all of the control blocks necessary for HyperSwap to manage 45,836 devices, all of the secondary devices must undergo a "pseudo online" process. 22,918 UCBs are initialized, every channel path x 22,918 devices must be validated as operational and connected to the correct device(s) and this also involves a process called "self description" where the -device- configuration data is read (for every secondary device) and then more z/OS control blocks are built from the device configuration data for a "topology" map (IOS CDT data) and all of this processing was performed in ~22 seconds
So what the customer is requesting is to optimize this process so that not all the addresses need to be 'reloaded' but just the ones that have changed. Maybe this involves changes from IOS and also from GDPS and DS8K code.

Idea priority High
  • Guest
    Reply
    |
    Aug 9, 2023

    I would like to get some additional comments and feedback. It seems that there are multiple problem statements being asked in this idea.

    • Reduce amount of CPU consumption when removing PPRC links in an active HyperSwap configuration. GDPS idea ZGDPS-I-144 made improvements to this area in GDPS Metro 4.5.

    • The ability to have the HyperSwap API in general take action only on devices that were added or removed from the HyperSwap configuration. E.g., the ability to add new devices to a new HyperSwap configuration without requiring unloading and reloading the entire configuration.


    I would like to expand on that second problem statement to understand the use cases and the scope of the problem.

    1. Are there other use cases where devices need to be added or removed to an active HyperSwap configuration?

    2. How often do these actions occur?

    3. Is your use case in a CSM z/OS HyperSwap or GDPS Metro environment?

    4. When performing these actions, is CPU usage still a major issue?

    5. When performing these actions, is the elapsed time where there is no HyperSwap protection still a major issue?

    We appreciate any input or additional comments. Please either post the comments here, or email me at tpowels@us.ibm.com


    Regards,

    Tabor Powelson, IOS and z/OS HyperSwap Design and Development