Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
On Mon, 6 Dec 2021 at 19:10, David Boyes wrote: > 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. > I think you're making it too hard and re-inventing things we already have. I believe we did the "signal shutdown" to mimic what the hardware does to tell the operating system to get out. Most like z/OS today already triggers SA etc to stop subsystems when applicable, just like z/VM can. And so does Linux. For CMS applications can use SHUTTRAP to do what they need to close shop. The missing piece we were discussing was a pipeline stage that can listen for the event and send a record into the pipeline to close a GATE or so to roll up the pipe. If you want, you can today already create a virtual machine that offers notifications through IUCV. So my application would connect to application AMBER in user SYSALERT, and wait for something to happen. To avoid race conditions, you probably need to provide the current status of the alert when the connection is established. But maybe something like MQ is a better approach than inventing your own. Rob
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
On Monday, 12/06/2021 at 06:10 GMT, "David Boyes" wrote: > 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. *SIGNAL requires that you be a member of a GCS group. You really want individual virtual machines to register for the signal so that QUERY SIGNALS will show meaningful status. If I add CMS Event Services support the CSL routine I wrote, then PIPE (or any other program) can easily listen for the event. Then, when the program is ready, it calls the CSL routine with the "quiesce" option. I just need to find the time. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
On 12/2/21, 10:33 AM, "CMSTSO Pipelines Discussion List on behalf of John P. Hartmann" 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 EXT 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?
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
On Thu, 2 Dec 2021 at 17:56, Bruce Hayden wrote: > +1 for me. What I do now is use SHUTTRAP to send an smsg that I trap in > STARMSG. For timezone changes, watch for the CP message via CP SET CPCONIO > IUCV. An external interrupt event stage would be welcomed. We age that those specific things would make sense. As always, the question is how much sense :-) >
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
+1 for me. What I do now is use SHUTTRAP to send an smsg that I trap in STARMSG. For timezone changes, watch for the CP message via CP SET CPCONIO IUCV. An external interrupt event stage would be welcomed. On Thu, Dec 2, 2021 at 8:58 AM David Boyes wrote: > Shooting the breeze a bit, a question arose as to how to best handle > processing the external interrupt used by SIGNAL SHUTDOWN to provide a tidy > way to terminate a server gracefully when things are supposed to shut down. > A quick look at the documentation doesn’t show any obvious way to do this, > so some questions: > > > 1. Is there an easy way to do this in pipes? > 2. If not, can this go on the list of round tuits for inclusion in the > base set of stages supplied with CMS? > > Since a lot of the new function in CMS seems to involve pipes these days, > it would seem to be a useful thing to have. > -- Bruce Hayden z/VM and Linux on IBM Z and LinuxONE IBM Advanced Technology Group
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
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. On 12/2/21 16:27, David Boyes wrote: There's nothing today, and it isn't easy if it isn't sent through something like *VMEVENT or STARMSG. One idea we kicked around would be to have an option to the PIPE command to arm/disarm a generic event handler for external interrupts and then a stage that was called when the event handler fired that would produce a string like EXTnnn on its output, which could be handled as needed. As you say, not straightforward, but it might be an idea worth looking at. Something to put on the wish list.
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
On Thursday, 12/02/2021 at 03:15 GMT, "Rob van der Heij" wrote: > There's nothing today, and it isn't easy if it isn't sent through something > like *VMEVENT or STARMSG. > > I can see the value of a pipeline application using a stage to subscribe to > asynchronous events that come in the form of specific external interrupts. > My pipeline-based service machine would then be able to respond to the > SIGNAL SHUTDOWN. I also envision CMS Pipelines wanting to know about time > zone changes, but I hadn't thought about whether that needs to be available > as an asynchronous event. Back in 2016 I started work on a CSL routine to work with shutdown signals. The basic start, stop, query, and "load quiesce PSW" functions were completed, but I shelved it before adding the CMS Event Services support. Without the event services support, all you can do is poll for the signal. Not too useful, IMO. PIPE would need a way to listen for that event. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
There's nothing today, and it isn't easy if it isn't sent through something like *VMEVENT or STARMSG. One idea we kicked around would be to have an option to the PIPE command to arm/disarm a generic event handler for external interrupts and then a stage that was called when the event handler fired that would produce a string like EXTnnn on its output, which could be handled as needed. As you say, not straightforward, but it might be an idea worth looking at. Something to put on the wish list.
Re: [CMS-PIPELINES] Pipe stage for detecting specific external interruptions
On Thu, 2 Dec 2021 at 15:58, David Boyes wrote: > Shooting the breeze a bit, a question arose as to how to best handle > processing the external interrupt used by SIGNAL SHUTDOWN to provide a tidy > way to terminate a server gracefully when things are supposed to shut down. > A quick look at the documentation doesn’t show any obvious way to do this, > so some questions: > > > 1. Is there an easy way to do this in pipes? > 2. If not, can this go on the list of round tuits for inclusion in the > base set of stages supplied with CMS? > > Since a lot of the new function in CMS seems to involve pipes these days, > it would seem to be a useful thing to have. > There's nothing today, and it isn't easy if it isn't sent through something like *VMEVENT or STARMSG. I can see the value of a pipeline application using a stage to subscribe to asynchronous events that come in the form of specific external interrupts. My pipeline-based service machine would then be able to respond to the SIGNAL SHUTDOWN. I also envision CMS Pipelines wanting to know about time zone changes, but I hadn't thought about whether that needs to be available as an asynchronous event. Sir Rob the Plumber
