In a SSI environment with VMSCHED setup as a USER entity and using IUCV to communicate from all members to the one member running the VMSCHED server every command is propagated to the one server including the END command used to terminate the server normally without crashing it.
I would like to see the VMSCHED server register for the SIGNAL SHUTDOWN interrupt like VMBACKUP does so that when a SIGNAL SHUTDOWN ALL command is issued VMSCHED will only shut down on the real system it is running on and when it is being shut down for an IPL or maintenance.
Any suggestions of terminating VMSCHED normally without performing a special test for VMSCHED to see if it is DSC or SSI using CP QUERY VMSCHED?
Sounds good to me -- in fact, in general how hard would it be to have all the VM:Manager products register for SIGNAL SHUTDOWN and do a orderly shutdown when received? It'd be awfully nice to have the products react in a defensive/intelligent way to being told the system is going down around their ears.
Can't agree more. Especially things like VMBATCH, VMSCHED...
As you mention, VM:Backup 3.6 has Signal Shutdown support, it was added during the development of VM:Backup 3.6. At that time Signal Shutdown support was also added to the VM:Manager Common Nucleus (level 5.1) which is the current development version.
For the products that currently run on the VM:Manager Common Nucleus (VM:Tape, VM:Schedule, VM:Secure/Director, VM:Archiver, VM:Operator, Explore), the Common Nuclues support can be retrofit via a PTF for each product.
Research will need to be done for the remaining products (VM:Spool, VM:Batch) to see what can be done to add Signal Shutdown support.
I am glad to see that you are on the path to making this a reality and it makes complete sense to make this a part of the Common Nucleus. Please make it an option for at least some of the products like VM:Secure and VM:Operator, VM:Secure for the reason that if Rules are active it may prevent other functions or shutdown processes from completing also VM:Operator needs to be able to maintain automated responses to messages until the last possible moment. I am sure this has been considered and the options will be in place when these functions are made GA.