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
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.
The TPF lab reconsidered this RFE based on the updated requirements but we still do not expect to implement this in the foreseeable future based on resources and priorities.
I received an email saying I could ask for this to be reconsidered. The original request may have been too complex, allowing for utilities to complete, processors to be taken offline etc. I'd like to simply the requirements:
A new Z-functional command to turn on/off the ability for TPF to be notified of a signal-shutdown event through external interrupt 2401.
Something like:
ZSHUT ENABLE - enables the TPF system to receive a signal-shutdown interrupt
ZSHUT DISABLE - disables the TPF system from seeing/acting on signal-shutdown interrupts.
ZSHUT QUERY - reports ENABLED or DISABLED
The disable and query options are optional, but should be provided.
On receipt of a signal shutdown interrupt, TPF should display a message on the console like "Hypervisor-initiated shutdown - ZCYCL 1052 starting".
If the system is already in 1052 state, or on reaching 1052 state, and a signal shutdown interrupt was received (as opposed to a manual ZCYCL 1052) then TPF should load the special PSW indicating "shutdown complete".
Whether you want TPF to be enbled for these events by default at each IPL is up to you. A default of disabled (current behavior) is fine, it can be turned on as required.
Based on resources and priorities, IBM does not expect to implement this in the foreseeable future.
You asked some questions privately. The last tmie I answered privately, the answers eem to get lost, so I'm answering publically... nothign sensitive here. :-)
LPAR deactivation - rare, my point is the code could be the same whether TPF is running on zVM or "bare metal".
zVM system shutdown - I'd say monthly, but it varies a lot. Seems sometmies we have a lot of changes that require an IPL, then other times we go months without a zVM outage.
#CP SIGNAL SHUTDOWN - rare
CP FORCE LOGOFF - dozens per day
Isn't the same EXT 2401 interrupt presented in all the above cases? No need to differentiate one cause from another.
Our policer is based strictly on elapsed time... we have many developers that bring up their own TPF test systems (often muli-TPF system configurations) and they rarely go to the trouble of shutting them down (they run disconnected in most cases) After a configurable delay, each TPF system is CP FORCED off, idle or not.
For other purposes I'd love to be able to detect "idle TPF systems"... but I don't know how possible that is. Even if there's nothing on the input or IO list for ages, thre's always a timer interrupt happening and TPF does "something". If you have suggestions for detecting how long a TPF system has been idle, I'd love to hear it, but that's outside the scope of this RFE. Even if I could detect an idle TPF system, I'd then want to CP FORCE LOGOFF, and it needs to handle the resulting EXT 2401 interrupt and shutdown gracefully.
If TPF handled the EXT 2401 interrupt and shut itself down gracefully, that would go a long way to keeping TPF (test) systems in good condition so the system could be resumed later with no ill effects.
Thanks for considering the enhancement. It also benefits production-type environmenets where zTPF is running with out zVM.
If an LPAR is deactivated/shutdown without first shutting zTPF down, the interrupt would cause zTPF to shutdown gracefully instead of possibly losing data.
I received a "private comment" asking for more information, and I replied "privately" back in July. This stilll shows "more info needed".
I'll recap here as a "public" comment.
My original request suggested that TPF should ZCYCL 1052 on receipt of a signal shutdown interrupt... turns out that's a bit too simplistic, and something like ZPSMS PR DEAC is more suitable.
What I'm looking for is that TPF, running on zVM should shutdown gracefully and log off on receiving a SIGNAL SHUTDOWN interrupt as a result of CP FORCE or SYSTEM SHUTDOWN, or #CP SIGNAL SHUTDOWN. (Similar to how zLinux shuts itself down nicely in those cases)
The acual mechanism of how to shut down, I leave to the TPF experts, but my requirement is for TPF test systems running on zVM to shutdown cleanly when being forced off or the zVM system is shutting down, etc. TPF needs to enable itself for the 2401 external interrupt and take the necessary action to quiesce itself and finally signal that the "shut down is complete", presumably by loading one of the magic PSWs.
Thanks,
Donald Russell