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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
How can I help you? What Information do you need?
I am unable to provide specifics about the issue we encountered as it was several years ago, likely on an EC12 processor. I can only attempt to recall specifics. The CEC likely had ~6 physical processors with these LPARs sharing the GPs:
Prod1 - 5 online logical processors
Prod2 - 5 online logical processors
Prod3 - 5 online logical processors
Dev - 3 online logical processors
Sandbox - 2 online logical processors, although more may have been online
If I recall correctly, when the ACTIVATE TEST was issued on the Sandbox LPAR, the processors became so busy that the Prod LPARs could not get the required CPU impacting (timeouts) transactions that are sensitive to response time.
Even though, we have set appropriate LPAR weights and logical processors, we still do not issue ACTIVATE TEST commands until we are in an approved change window when transaction rates are low. Since we do not try the TEST, there is a possibility that problems with the new IODF are not discovered in a timely manner.
As another poster suggested, a lower dispatching priority of an ACTIVATE TEST with a longer elapsed time seems reasonable to me.
Would another option be to initiate the TEST function via an HCD batch program/job or with a new parm to indicate a lower DP is desired?
Thank you
We suspect that the performance problem happens in IOS.
We talked to the IOS team and they will investigate.
We will re-route this requirement to their queue.
Kind regards,
Your HCD team
Hello Team,
I observed a similar behavior when testing a new IODF. May I suggest that for testing only the Dispatch Priority of the associated processes (IOS), while comparing the configurations, may be temporarily lowered as to no interfere with operations of running applications? The test may take longer, but the application processing should not be interrupted.
I do not have a very complex SYSPLEX to test with, so I cannot give appropriate results, but I do understand the OP's concern. In our environment, we do not use ACTIVATE (not even TEST) on the production CPC, because of that.
Thank you
Roger Suhr
thanks for your comment.
We have no reference to the problem you refer to. Anyhow, a dynamic activate, even a test one, requires to compare two processor configurations
and to check the current device status of affected I/O definitions. We know that this can be CPU time consuming. Nevertheless, there are many means in z/OS and the IBM Z server that allow you to control/reduce the effect of this processing on other (production) LPARs.
In order to understand the impact, we first need some kind of analysis, which part of the activation requires the excessing amount of time in your case. Be aware that HCD is comparing the I/O configurations while the status checking is done within another component in z/OS (IOS).
Can you provide some more details?
You may contact our service Id IBMHCD@de.ibm.com
Kind regards,
Your HCD Team
Hello HCD Team,
unfortunately this was no defect. We opened case TS008730222 for that.
If you need further information feel free to contact me.
regards Juergen
thank you for the requirement.
Your description contains the information that your LPAR stopped during a test activate. That sounds more like a defect than as a requirement.
If the LPAR really stopped, can you please provide a link to the hardware case where we can get more information to understand what the problem was.
If something else happened, please provide a more detailed description, so that we can understand the requirement in more detail.
Kind regards,
Your HCD Team
Some years back, we encountered similar impact. On a CEC with production and sandbox LPARs, we issued ACTIVATE IODF=xx,TEST on the sandbox LPAR. The ACTIVATE TEST consumed so much CPU on the sandbox LPAR that our production LPARs were starved of CPU which impacted our high volume payment authorization tasks.