On 12/2/21, 10:33 AM, "CMSTSO Pipelines Discussion List on behalf of John P.
Hartmann" <CMS-PIPELINES@VM.MARIST.EDU on behalf of m...@jphartmann.eu> wrote:
You would want a stage that connects to the timezone (or whatever)
service and then writes a record when the event occurs. STARxxx does
this for most system services. I'd suggest that be the paradigm.
How does this strike you:
1. Create a virtual machine SYSALERT running an application (maybe the
existing SHUTTRAP tool) that enables an external interrupt handler and connects
to *SIGNAL with a specific group id and waits for an external interrupt other
than the special ones IUCV uses. Multiple copies of the SYSALERT machine can
exist so long as one copy is still running and a member of the group at the
time of the event.
2. Set a CP variable to record the virtual “I’m interested in shutdown
notifications” *SIGNAL group id created on this system.
3. Each server that is interested in the controlled shutdown reads the CP
variable, connects to *SIGNAL and joins the virtual machine group by adding a
pipeline to listen to *SIGNAL. This registers the virtual machine as interested
in being informed of a shutdown or other event.
4. When the external interrupt arrives, SYSALERT wakes up and uses *SIGNAL to
broadcast a EXTxxxx message to the virtual machine group.
5. All interested servers accept the broadcast message via their connection to
*SIGNAL and initiate a graceful termination.
6. For neatness sake, if it’s the shutdown interrupt, SYSALERT disconnects
from *SIGNAL and logs off. Otherwise keep running for as long as needed.
We don’t need to have VM development involved in adding stuff to CP, and it can
be done comparatively quickly. When they do get enough tuits and get around to
add defined shutdown and timezone change events to *VMEVENT, SYSALERT just
switches to listening to *VMALERT and continues to function as before. We could
even develop a z/OS application to listen to *SIGNAL and trigger shutdown
automation on the right message.
Comments?
