Re: Signal support
>SHUTTRAP could be easily modified to run as a CMS MT root child > process. > The new code would run as a separate process within CMS and not interfere > with concurrent processes. I use the "root child" trick to run CMS > commmands > as "background tasks". There are some restrictions for "background > tasks", > but SHUTTRAP could be coded to avoid them. Neat. That would probably handle the CMS-based WWW servers, or other CMS MT widgets nicely. >No modification to CMS needed. GCS would be another story, however. Since GCS is derived from MVT, does anyone know what the MVS world does with the shutdown signal? I wonder if any of that code could be "borrowed". -- db
Re: Signal support
> Shortly after I posted the last one, I realized this problem. I cannot > > just set up a web server (or whatever) to handle the SHUTDOWN signal and > > LOGOFF. If I do, TCP/IP will just bring it back up again! I would at leas > t > need an interface to say "quit watching me, please!". IMHO, that would be part of the stack shutdown -- as Chuckie indicated, stop the new connection listener, but also disable the auto-restart monitor at the same time -- if the stack knows it is going down, it shouldn't be resetting stuff any longer. If a server fails and the stack is in shutdown-in-progress, force/autolog won't win anyway -- nothing to connect to. The application servers would be the next targets, but if they got an EIO from socket communications, then the logical thing to do is shut down. What the individual app might do with a shutdown signal is going to be application specific; "do what makes sense", but with a common trigger to initiate that processing.
Re: Signal support
Shortly after I posted the last one, I realized this problem. I cannot just set up a web server (or whatever) to handle the SHUTDOWN signal and LOGOFF. If I do, TCP/IP will just bring it back up again! I would at leas t need an interface to say "quit watching me, please!". Otherwise, I need both TCP/IP and the server to respond to the SHUTDOWN signal. Practically, though, web servers aren't a good example. My idea of shutting down a web server cleanly is to complete all pending units of work (or roll them back) and respond to all user transactions with a message "The world is going to end soon!". I don't really want to logoff. I'm on the fence about whether we need a TCP/IP SHUTDOWN. The one example I have seen here of needing it is the behavior of some old communication controllers when not properly quiesced. But if its only the old ones, the n then the response to the requirement is "Available". Does anyone have a real example? Otherwise, it puts this requirement in the "Nice to Have" category -- and I won't write it. On Wed, 9 Aug 2006 17:22:37 -0400, Alan Altmark <[EMAIL PROTECTED]> wrote: >On Wednesday, 08/09/2006 at 02:28 EST, Alan Ackerman ><[EMAIL PROTECTED]> wrote: > >> I'm not sure whether the TCP/IP stack maintains state or not, > >It doesn't. > >> Just providing SHUTDOWN support for the TCP/IP stack isn't enough, >either, >> it would have to pass this along to its guests. (What does TCP/IP do >when >> it gets a CP EXT?) Maybe it's just simpler to have each guest register >for >> the shutdown signal itself? > >There is no way to pass the "shutting down" signal to C/IUCV/REXX/PIPE >socket applications. > >The one thing the TCPIP server perhaps *should* do upon getting a shutdo wn >signal is to turn off the listening port monitor. That would allow the >apps to do what needs to be done on a case-by-case basis. No automatic CP >EXT since that could interfere with a "transaction". I would find it >highly annoying to have an app close its listening socket, just to have >the stack force/autolog it. I'm taking this one under advisement. > >Alan Altmark >z/VM Development >IBM Endicott > =
Re: Signal support
> The Pascal socket interface actually sends a "shuttingdown" signal to the > clients. NETSTAT CP EXT is ok for that. But who wants to write Pascal > code? That's why you folks make the big bucks. Dirty deeds, done dirt cheap. 8-) > There's no provision for it in BSD sockets. Two implementation possibilities from the BSD socket world: MSG_OOB. Pending shutdown or other implementation-specific operation details are exactly what out-of-band messages are for (and in fact, there is direct precedent in that the TOPS-20 IP stack does in fact use OOB messages for signaling impending stack outage, as did the Xerox Dandelion and early 4.2BSD stack. I'd have to check, but I think the 4.3 stack still did, but not certain...8-)). You could also return ENETDOWN or better yet, EIO on connections that are pending shutdown. EIO is normally returned only for Unix-domain sockets, but there's no filesystem to generate errors from here, and it would logically map to the same function (in that there's an IUCV SEVER waiting in the wings once the stack is dead, so there would definitely be an I/O error in it's future...)
Re: Signal support
> SHARE in its infinite wisdom has decoupled requirements from SHARE > meetings. We don't have any meetings to look at or submit requirements -- > it's all done on a web page. I just haven't figured out the latest > iteration of same. I'm afraid the result of that has been to decrease > interest in the whole requirements process -- but I could be wrong. (Does > anyone measure these things?) I gave up on the SHARE requirements tool a long time ago. WAVV's process is both simple and effective. Check it out: http://www.wavv.org/wavv_requirements_new.shtml. 15 minutes from start to finish to construct, format and submit a requirement, and most of it spent actually thinking about the requirement. Hard to beat, that. -- db
Re: Signal support
On Wednesday, 08/09/2006 at 10:34 AST, David Boyes <[EMAIL PROTECTED]> wrote: > Clearly at some point in the past, there was a need for a clean shutdown > and cleanup of what you're doing; otherwise the #CP EXT code wouldn't be > there. Modifying it to catch the architected signal and do the same > thing instead of faking it with a SHUTTRAP-based kludge is the Right > Thing to Do. In the dim Mists of Tyme, maybe. The Pascal socket interface actually sends a "shuttingdown" signal to the clients. NETSTAT CP EXT is ok for that. But who wants to write Pascal code? There's no provision for it in BSD sockets. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Hi, SHUTTRAP could be easily modified to run as a CMS MT root child process. The new code would run as a separate process within CMS and not interfere with concurrent processes. I use the "root child" trick to run CMS commmands as "background tasks". There are some restrictions for "background tasks", but SHUTTRAP could be coded to avoid them. No modification to CMS needed. GCS would be another story, however. Cheers, Arty
Re: Signal support
On Wednesday, 08/09/2006 at 02:14 AST, David Boyes <[EMAIL PROTECTED]> wrote: > I'll give you the benefit of the doubt that this may have all been fixed > in new releases, but every one of those things is a guaranteed level 3 > support call that'll haul you (or someone you have to face every day) > out of bed at 2 AM. Wouldn't it be simpler to just prevent them in a way > that would avoid the problem entirely? In a perfect world with infinite resources, I would propose that we add real shutdown support to all the subsystems. Just because it *might* prevent a problem. But we don't have infinite resources, so we pick and choose. This doesn't make the cut. Sorry. > ??? How does this *increase* complexity, and for whom? If CP SEND TCPIP > #CP EXT does what we want it to do, how does causing SIGNAL TCPIP > SHUTDOWN to do the same thing make that any worse? It certainly > *decreases* complexity for the user -- no "use SIGNAL SHUTDOWN to > stop everything, except for these things which use X, and these > which use Y, and these ones over here which don't have any shutdown > command...". If a CP SHUTDOWN hangs while a bunch of servers are doing unneeded activity, it's a waste of our time and yours. > Isn't that what we're doing here? RSCS is a task running in a GCS-based > OS. CMS MT is arguably a single user OS. Etc. LOL! You made my day. Sure, they're both single-user operating systems, but neither exhibits properties that require shutdown. This *must* be true because there is no CMS or GCS shutdown command! :-) The applications, OTOH, *may* have those properties. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
On Wednesday, 08/09/2006 at 02:28 EST, Alan Ackerman <[EMAIL PROTECTED]> wrote: > I'm not sure whether the TCP/IP stack maintains state or not, It doesn't. > Just providing SHUTDOWN support for the TCP/IP stack isn't enough, either, > it would have to pass this along to its guests. (What does TCP/IP do when > it gets a CP EXT?) Maybe it's just simpler to have each guest register for > the shutdown signal itself? There is no way to pass the "shutting down" signal to C/IUCV/REXX/PIPE socket applications. The one thing the TCPIP server perhaps *should* do upon getting a shutdown signal is to turn off the listening port monitor. That would allow the apps to do what needs to be done on a case-by-case basis. No automatic CP EXT since that could interfere with a "transaction". I would find it highly annoying to have an app close its listening socket, just to have the stack force/autolog it. I'm taking this one under advisement. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
I don't really agree with this "we've always tolerated pulling the rug ou t from under us so we shouldn't change it now". The fact is, I've spent lot s of time in my professional life fixing things that happened because of a shutdown. And we've written code to deal with this, or fix it afterwards. It seems to me that the SHUTDOWN signal is an opportunity to relace all these ad-hoc solutions with a more general one. You say it wasn't designe d for that, but in that case we need something else that IS. Do I have to write that requirement? What's wrong with extending the SHUTDOWN concept to further levels, now that we have a command to do it? I like the idea o f adding CMS (and GCS) nucleus services to implement SHUTTRAP. I'm not sure whether the TCP/IP stack maintains state or not, but some of the guests it supports do -- web servers, for example. I could write a requirement to the vendor of the web servers to support shutdown, of course. Again, this is more ad-hoc, one at a time activity. But I think there will always have to be a per-application part of the code. Just providing SHUTDOWN support for the TCP/IP stack isn't enough, either , it would have to pass this along to its guests. (What does TCP/IP do when it gets a CP EXT?) Maybe it's just simpler to have each guest register fo r the shutdown signal itself? On Wed, 9 Aug 2006 13:23:21 -0400, Alan Altmark <[EMAIL PROTECTED]> wrote: >The LPAR deactivation signal was designed to allow *operating systems* t o >flush cache, checkpoint and bring themselves down as quickly as possible . >We wanted to avoid Linux fsck's on their EXT2 filesystems. (Now folks ha ve >moved to ext3. Harrumph.) It really wasn't meant to be a leisurely >stroll so that all the apps that haven't needed it in the prior century >can all of a sudden wave Goodbye. > >Alan Altmark >z/VM Development >IBM Endicott > =
Re: Signal support
Thanks to DB, I have sent in a WAVV requirement to add support to GCS and RSCS. Our other GCS member, VTAM, is not included as a laughter-suppression action. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Alan Ackerman > Sent: Wednesday, August 09, 2006 12:10 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Signal support > > > SHARE in its infinite wisdom has decoupled requirements from SHARE > meetings. We don't have any meetings to look at or submit > requirements --= > > it's all done on a web page. I just haven't figured out the latest > iteration of same. I'm afraid the result of that has been to decrease > interest in the whole requirements process -- but I could be > wrong. (Does= > > anyone measure these things?) > > I'm glad I asked here, because you all have given me a number > of differen= > t > ideas for requirements I could write. I don't feel ready to > write one -- = > > but that doesn't mean someone else can't. We can certainly > keep discussin= > g > it here, and at I will be at SHARE next week to discuss it > further with = > > anyone who is intereseted. > > On Wed, 9 Aug 2006 07:07:27 -0500, Rich Smrcina > <[EMAIL PROTECTED]> wrot= > e: > > >Is it too late to write one for SHARE next week? A WAVV requirement > >won't be received until late next May. > > > >Rich Smrcina > >VM Assist, Inc. > >Phone: 414-491-6001 > >Ans Service: 360-715-2467 > >rich.smrcina at vmassist.com > > > >Catch the WAVV! http://www.wavv.org > >WAVV 2007 - Green Bay, WI - May 18-22, 2007 > >= > == > >
Re: Signal support
SHARE in its infinite wisdom has decoupled requirements from SHARE meetings. We don't have any meetings to look at or submit requirements -- it's all done on a web page. I just haven't figured out the latest iteration of same. I'm afraid the result of that has been to decrease interest in the whole requirements process -- but I could be wrong. (Does anyone measure these things?) I'm glad I asked here, because you all have given me a number of differen t ideas for requirements I could write. I don't feel ready to write one -- but that doesn't mean someone else can't. We can certainly keep discussin g it here, and at I will be at SHARE next week to discuss it further with anyone who is intereseted. On Wed, 9 Aug 2006 07:07:27 -0500, Rich Smrcina <[EMAIL PROTECTED]> wrot e: >Is it too late to write one for SHARE next week? A WAVV requirement >won't be received until late next May. > >Rich Smrcina >VM Assist, Inc. >Phone: 414-491-6001 >Ans Service: 360-715-2467 >rich.smrcina at vmassist.com > >Catch the WAVV! http://www.wavv.org >WAVV 2007 - Green Bay, WI - May 18-22, 2007 > =
Re: Signal support
Title: RE: Signal support And once you’re running CMS multitasking, it’s not really CMS any more, although that’s an interesting argument: adding it to the CMS MT library and providing a thread automatically that waited for the signal and then drove the CMS MT termination code for MT apps. That much development is probably beyond what we can ask IBM to do reasonably, I’d think. Putting it into CMS would be a pretty major internal change that messes with a lot of longstanding assumptions about CMS internals. The number of CMS MT programs is much smaller, and the number of non-IBM GCS programs is even smaller than that, so you could probably do it safely there, but the applications that would benefit are the ones we’ve been talking about here (RSCS, RACF, TCPIP, etc) which could be enabled much easier by direct modification. David Boyes Sine Nomine Associates From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 09, 2006 2:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support RSCS is in the GCS group, not a CMS application. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Huegel, Thomas Sent: Wednesday, August 09, 2006 11:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support Maybe the requirement should to put the Signal Support directly into the CMS Nucleus, that way applications that run under CMS wouldn't need to be changed.. or
Re: Signal support
Good angle, but the applications would need to be modified to process
the signal (or whatever it gets morphed in to once CMS or GCS get it).
Maybe command can be added to PROFILE EXEC and/or PROFILE GCS that tells
the virtual machine how to handle the signal (stack a command, logoff,
whatever).
Huegel, Thomas wrote:
That is correct, so put it in GCS too, my point was that putting it in
the 'nucleus' would be better than adding it to every application that
is served by said nucleus.
-Original Message-
*From:* The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of *Schuh, Richard
*Sent:* Wednesday, August 09, 2006 1:35 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: Signal support
RSCS is in the GCS group, not a CMS application.
Regards,
Richard Schuh
-Original Message-
*From:* The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of *Huegel, Thomas
*Sent:* Wednesday, August 09, 2006 11:28 AM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: Signal support
Maybe the requirement should to put the Signal Support directly
into the CMS Nucleus, that way applications that run under CMS
wouldn't need to be changed.. or something like that.
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED]
Behalf Of Mike Walter
Sent: Wednesday, August 09, 2006 1:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Signal support
I'm typing the following in my best Southern accent... All
y'all type
faster then I ken read! :-)
It's been a fascinating discussion and a credit to the members
of the list
that such discussions can be had without a single flame or negative
personal comment.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
"David Boyes" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
08/09/2006 01:14 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Signal support
> Or at all? "No worries, mate. Just shutdown your
> system. Everything will be ok. Sleep tight."
Ah, but how does the system guarantee this to be the case without a
consistently applied methodology of how things start and
terminate? In
the current setup, you can *guess* that it happened OK, but can you
provide a contractual guarantee that the system will be OK? I don't
think so.
Consider the difference between "kill -HUP" and "kill -TERM".
> (Note to self: see if
> that gecko is looking to make a change. He would be good at
this.)
Check out the new Novell partner ad cards. The ninja gecko card is
pretty cool. 8-)
> Consistency? WDNNSC. NJE signon/signoff has been tolerating
the
> unexpected loss and reappearance of the remote host for decades.
Link setup and connection, yes. The RSCS supervisor itself
always had a
clean initiation and termination process (I no longer have a
RSCS v1
instance, but RSCS v2 certainly did anyway).
Note that RSCS is also responsible for cleanly shutting down
whatever
tasks it started to avoid making GCS sick...8-) It may not
matter in the
context of a entire system shutdown, but it's still illustrative
of good
behavior.
> RACF,
> RSCS, SFS, and TCP/IP don't *need* shutdown.
I guess I've repaired one too many corrupted RACF databases to
buy that
RACF doesn't need a clean shutdown to reliably operate,
especially in
shared database mode. And had one too many hung I/Os on TCPIP
userids.
And one too many corrupted SFS catalogs.
I'll give you the benefit of the doubt that this may have all
been fixed
in new releases, but every one of those things is a guaranteed
level 3
support call that'll haul you (or someone you have to face every
day)
out of bed at 2 AM. Wouldn't it be simpler to just prevent them
in a way
that would avoid the problem entirely?
> Dave was right, IMO: It
> would be nice, but there's no technical requirement for it. I'd
rather
> not introduce complexity and delay without benefit. (Believe
me, I
Re: Signal support
Title: RE: Signal support
That
is correct, so put it in GCS too, my point was that putting it in the 'nucleus'
would be better than adding it to every application that is served by said
nucleus.
-Original Message-From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On Behalf Of Schuh,
RichardSent: Wednesday, August 09, 2006 1:35 PMTo:
IBMVM@LISTSERV.UARK.EDUSubject: Re: Signal
support
RSCS is in
the GCS group, not a CMS application.
Regards, Richard Schuh
-Original Message-From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On Behalf Of Huegel,
ThomasSent: Wednesday, August 09, 2006 11:28 AMTo:
IBMVM@LISTSERV.UARK.EDUSubject: Re: Signal
support
Maybe the requirement should to put the Signal
Support directly into the CMS Nucleus, that way applications that run under
CMS wouldn't need to be changed.. or something like that.
-Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On
Behalf Of Mike Walter Sent: Wednesday, August 09, 2006 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support
I'm typing the following in my best Southern
accent... All y'all type faster
then I ken read! :-)
It's been a fascinating discussion and a credit
to the members of the list that such
discussions can be had without a single flame or negative personal comment.
Mike Walter Hewitt Associates Any opinions
expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates.
"David Boyes" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
08/09/2006 01:14 PM Please respond
to "The IBM z/VM Operating System"
To IBMVM@LISTSERV.UARK.EDU cc
Subject Re:
Signal support
> Or at all? "No worries, mate.
Just shutdown your > system.
Everything will be ok. Sleep tight."
Ah, but how does the system guarantee this to be
the case without a consistently applied
methodology of how things start and terminate? In the current setup, you can *guess* that it happened OK,
but can you provide a contractual
guarantee that the system will be OK? I don't think so.
Consider the difference between "kill -HUP" and
"kill -TERM".
> (Note to self: see if > that gecko is looking to make a change. He
would be good at this.)
Check out the new Novell partner ad cards. The
ninja gecko card is pretty cool.
8-) > Consistency? WDNNSC. NJE signon/signoff has been
tolerating the > unexpected loss and
reappearance of the remote host for decades.
Link setup and connection, yes. The RSCS
supervisor itself always had a clean
initiation and termination process (I no longer have a RSCS v1
instance, but RSCS v2 certainly did anyway).
Note that RSCS is also responsible for cleanly
shutting down whatever tasks it started
to avoid making GCS sick...8-) It may not matter in the context of a entire system shutdown, but it's still
illustrative of good behavior.
> RACF, > RSCS, SFS, and TCP/IP don't *need* shutdown.
I guess I've repaired one too many corrupted RACF
databases to buy that RACF doesn't need a
clean shutdown to reliably operate, especially in shared database mode. And had one too many hung I/Os on
TCPIP userids. And one too many corrupted
SFS catalogs.
I'll give you the benefit of the doubt that this
may have all been fixed in new releases,
but every one of those things is a guaranteed level 3 support call that'll haul you (or someone you have to face
every day) out of bed at 2 AM. Wouldn't
it be simpler to just prevent them in a way that would avoid the problem entirely?
> Dave was right, IMO: It
> would be nice, but there's no technical
requirement for it. I'd rather > not introduce
complexity and delay without benefit. (Believe me, I like > the symmetry
of a system shutting down the opposite way it came up. > Therapy is helping.)
??? How does this *increase* complexity, and for
whom? If CP SEND TCPIP #CP EXT does what
we want it to do, how does causing SIGNAL TCPIP SHUTDOWN to do the same thing make that any worse? It
certainly *decreases* complexity for the
user -- no "use SIGNAL SHUTDOWN to stop everything, except for these things which use X, and
these which use Y, and these ones
over here which don't have any shutdown command...".
> The LPAR deactivation signal was designed to
allow *operating systems* to
> flush cache, checkpoint and bring
thems
Re: Signal support
Probably should be in GCS *and* RSCS, as the shutdown of GCS is interrelated, and if GCS terminates, it has a chance of signaling all it's tasks to terminate as well, covering VTAM, Netview, RSCS, etc as well. I sent Richard a filled-in requirement form that summarizes the discussion so far. If he wants to submit it, cool...8-) > Maybe on VM it has, but I have found that a clean shutdown of RSCS goes a > long way toward preventing operational headaches when trying to reconnect > to z/OS or MVS systems. Before I created a SHUTDOWN EXEC that tells RSCS > to SHUTDOWN QUICK, many of our MVS systems would have to drain the link > and restart it. Sometimes, there were time dependencies - a link would > have to be drained on both the MVS system and on VM; then the start order > needed to be VM first, JES next. Following the SHUTDOWN QUICK, we have > only one problem link and it is consistent. It does start after about 15 > minutes.
Re: Signal support
It does have the appearance of being a bug, but probably not one in RSCS. I think that the SHUTDOWN QUICK is really a circumvention of an MVS or VTAM bug. I know that an NJE link with RSCS at either end has no such problem. Would a requirement to enhance RSCS to circumvent a bug in another system be likely to be approved? Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of A. Harry Williams > Sent: Wednesday, August 09, 2006 11:16 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Signal support > > > On Wed, 9 Aug 2006 14:10:05 -0400 Alan Altmark said: > >On Wednesday, 08/09/2006 at 11:02 MST, "Schuh, Richard" > <[EMAIL PROTECTED]> > >wrote: > >> Maybe on VM it has, but I have found that a clean shutdown > of RSCS goes > >a long > >> way toward preventing operational headaches when trying to > reconnect to > >z/OS or > >> MVS systems. Before I created a SHUTDOWN EXEC that tells RSCS to > >SHUTDOWN > >> QUICK, many of our MVS systems would have to drain the > link and restart > >it. > >> Sometimes, there were time dependencies - a link would have to be > >drained on > >> both the MVS system and on VM; then the start order needed to be VM > >first, JES > >> next. Following the SHUTDOWN QUICK, we have only one > problem link and it > >is > >> consistent. It does start after about 15 minutes. > > > >I'm not sure that you're aren't describing a bug somewhere, but is it > >technical problem that you say can be reasonably avoided by orderly > >shutdown. So I'd say: write up an RSCS requirement to support signal > >shutdown. > > It may be a bug, but it's a persistent bug. We've had the "problem" > for years. Therapy helped, as did banging our heads on the > concrete wall > outside. We finally settled on Netview automation on the MVS side to > look for the problem, drain and restart the link. A lot less > blood on the > floor. > > /ahw > > > > >Alan Altmark > >z/VM Development > >IBM Endicott >
Re: Signal support
Title: RE: Signal support RSCS is in the GCS group, not a CMS application. Regards, Richard Schuh -Original Message-From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Huegel, ThomasSent: Wednesday, August 09, 2006 11:28 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: Signal support Maybe the requirement should to put the Signal Support directly into the CMS Nucleus, that way applications that run under CMS wouldn't need to be changed.. or something like that. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Mike Walter Sent: Wednesday, August 09, 2006 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support I'm typing the following in my best Southern accent... All y'all type faster then I ken read! :-) It's been a fascinating discussion and a credit to the members of the list that such discussions can be had without a single flame or negative personal comment. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 08/09/2006 01:14 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support > Or at all? "No worries, mate. Just shutdown your > system. Everything will be ok. Sleep tight." Ah, but how does the system guarantee this to be the case without a consistently applied methodology of how things start and terminate? In the current setup, you can *guess* that it happened OK, but can you provide a contractual guarantee that the system will be OK? I don't think so. Consider the difference between "kill -HUP" and "kill -TERM". > (Note to self: see if > that gecko is looking to make a change. He would be good at this.) Check out the new Novell partner ad cards. The ninja gecko card is pretty cool. 8-) > Consistency? WDNNSC. NJE signon/signoff has been tolerating the > unexpected loss and reappearance of the remote host for decades. Link setup and connection, yes. The RSCS supervisor itself always had a clean initiation and termination process (I no longer have a RSCS v1 instance, but RSCS v2 certainly did anyway). Note that RSCS is also responsible for cleanly shutting down whatever tasks it started to avoid making GCS sick...8-) It may not matter in the context of a entire system shutdown, but it's still illustrative of good behavior. > RACF, > RSCS, SFS, and TCP/IP don't *need* shutdown. I guess I've repaired one too many corrupted RACF databases to buy that RACF doesn't need a clean shutdown to reliably operate, especially in shared database mode. And had one too many hung I/Os on TCPIP userids. And one too many corrupted SFS catalogs. I'll give you the benefit of the doubt that this may have all been fixed in new releases, but every one of those things is a guaranteed level 3 support call that'll haul you (or someone you have to face every day) out of bed at 2 AM. Wouldn't it be simpler to just prevent them in a way that would avoid the problem entirely? > Dave was right, IMO: It > would be nice, but there's no technical requirement for it. I'd rather > not introduce complexity and delay without benefit. (Believe me, I like > the symmetry of a system shutting down the opposite way it came up. > Therapy is helping.) ??? How does this *increase* complexity, and for whom? If CP SEND TCPIP #CP EXT does what we want it to do, how does causing SIGNAL TCPIP SHUTDOWN to do the same thing make that any worse? It certainly *decreases* complexity for the user -- no "use SIGNAL SHUTDOWN to stop everything, except for these things which use X, and these which use Y, and these ones over here which don't have any shutdown command...". > The LPAR deactivation signal was designed to allow *operating systems* to > flush cache, checkpoint and bring themselves down as quickly as possible. Isn't that what we're doing here? RSCS is a task running in a GCS-based OS. CMS MT is arguably a single user OS. Etc. > It really wasn't meant to be a leisurely > stroll so that all the apps that haven't needed it in the prior century > can all of a sudden wave Goodbye. So make the SIGNAL handler do the equivalent of Z NET,QUICK, and put in a regular STOP or SHUTDOWN command for the graceful shutdown. I could agree on that. Oh, well. I've written the requirement, so I feel
Re: Signal support
Title: RE: Signal support Maybe the requirement should to put the Signal Support directly into the CMS Nucleus, that way applications that run under CMS wouldn't need to be changed.. or something like that. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Mike Walter Sent: Wednesday, August 09, 2006 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support I'm typing the following in my best Southern accent... All y'all type faster then I ken read! :-) It's been a fascinating discussion and a credit to the members of the list that such discussions can be had without a single flame or negative personal comment. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 08/09/2006 01:14 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support > Or at all? "No worries, mate. Just shutdown your > system. Everything will be ok. Sleep tight." Ah, but how does the system guarantee this to be the case without a consistently applied methodology of how things start and terminate? In the current setup, you can *guess* that it happened OK, but can you provide a contractual guarantee that the system will be OK? I don't think so. Consider the difference between "kill -HUP" and "kill -TERM". > (Note to self: see if > that gecko is looking to make a change. He would be good at this.) Check out the new Novell partner ad cards. The ninja gecko card is pretty cool. 8-) > Consistency? WDNNSC. NJE signon/signoff has been tolerating the > unexpected loss and reappearance of the remote host for decades. Link setup and connection, yes. The RSCS supervisor itself always had a clean initiation and termination process (I no longer have a RSCS v1 instance, but RSCS v2 certainly did anyway). Note that RSCS is also responsible for cleanly shutting down whatever tasks it started to avoid making GCS sick...8-) It may not matter in the context of a entire system shutdown, but it's still illustrative of good behavior. > RACF, > RSCS, SFS, and TCP/IP don't *need* shutdown. I guess I've repaired one too many corrupted RACF databases to buy that RACF doesn't need a clean shutdown to reliably operate, especially in shared database mode. And had one too many hung I/Os on TCPIP userids. And one too many corrupted SFS catalogs. I'll give you the benefit of the doubt that this may have all been fixed in new releases, but every one of those things is a guaranteed level 3 support call that'll haul you (or someone you have to face every day) out of bed at 2 AM. Wouldn't it be simpler to just prevent them in a way that would avoid the problem entirely? > Dave was right, IMO: It > would be nice, but there's no technical requirement for it. I'd rather > not introduce complexity and delay without benefit. (Believe me, I like > the symmetry of a system shutting down the opposite way it came up. > Therapy is helping.) ??? How does this *increase* complexity, and for whom? If CP SEND TCPIP #CP EXT does what we want it to do, how does causing SIGNAL TCPIP SHUTDOWN to do the same thing make that any worse? It certainly *decreases* complexity for the user -- no "use SIGNAL SHUTDOWN to stop everything, except for these things which use X, and these which use Y, and these ones over here which don't have any shutdown command...". > The LPAR deactivation signal was designed to allow *operating systems* to > flush cache, checkpoint and bring themselves down as quickly as possible. Isn't that what we're doing here? RSCS is a task running in a GCS-based OS. CMS MT is arguably a single user OS. Etc. > It really wasn't meant to be a leisurely > stroll so that all the apps that haven't needed it in the prior century > can all of a sudden wave Goodbye. So make the SIGNAL handler do the equivalent of Z NET,QUICK, and put in a regular STOP or SHUTDOWN command for the graceful shutdown. I could agree on that. Oh, well. I've written the requirement, so I feel better. You can rank the giants as you see them, Pancho. 8-) -- db The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or
Re: Signal support
I'm typing the following in my best Southern accent... All y'all type faster then I ken read! :-) It's been a fascinating discussion and a credit to the members of the list that such discussions can be had without a single flame or negative personal comment. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 08/09/2006 01:14 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support > Or at all? "No worries, mate. Just shutdown your > system. Everything will be ok. Sleep tight." Ah, but how does the system guarantee this to be the case without a consistently applied methodology of how things start and terminate? In the current setup, you can *guess* that it happened OK, but can you provide a contractual guarantee that the system will be OK? I don't think so. Consider the difference between "kill -HUP" and "kill -TERM". > (Note to self: see if > that gecko is looking to make a change. He would be good at this.) Check out the new Novell partner ad cards. The ninja gecko card is pretty cool. 8-) > Consistency? WDNNSC. NJE signon/signoff has been tolerating the > unexpected loss and reappearance of the remote host for decades. Link setup and connection, yes. The RSCS supervisor itself always had a clean initiation and termination process (I no longer have a RSCS v1 instance, but RSCS v2 certainly did anyway). Note that RSCS is also responsible for cleanly shutting down whatever tasks it started to avoid making GCS sick...8-) It may not matter in the context of a entire system shutdown, but it's still illustrative of good behavior. > RACF, > RSCS, SFS, and TCP/IP don't *need* shutdown. I guess I've repaired one too many corrupted RACF databases to buy that RACF doesn't need a clean shutdown to reliably operate, especially in shared database mode. And had one too many hung I/Os on TCPIP userids. And one too many corrupted SFS catalogs. I'll give you the benefit of the doubt that this may have all been fixed in new releases, but every one of those things is a guaranteed level 3 support call that'll haul you (or someone you have to face every day) out of bed at 2 AM. Wouldn't it be simpler to just prevent them in a way that would avoid the problem entirely? > Dave was right, IMO: It > would be nice, but there's no technical requirement for it. I'd rather > not introduce complexity and delay without benefit. (Believe me, I like > the symmetry of a system shutting down the opposite way it came up. > Therapy is helping.) ??? How does this *increase* complexity, and for whom? If CP SEND TCPIP #CP EXT does what we want it to do, how does causing SIGNAL TCPIP SHUTDOWN to do the same thing make that any worse? It certainly *decreases* complexity for the user -- no "use SIGNAL SHUTDOWN to stop everything, except for these things which use X, and these which use Y, and these ones over here which don't have any shutdown command...". > The LPAR deactivation signal was designed to allow *operating systems* to > flush cache, checkpoint and bring themselves down as quickly as possible. Isn't that what we're doing here? RSCS is a task running in a GCS-based OS. CMS MT is arguably a single user OS. Etc. > It really wasn't meant to be a leisurely > stroll so that all the apps that haven't needed it in the prior century > can all of a sudden wave Goodbye. So make the SIGNAL handler do the equivalent of Z NET,QUICK, and put in a regular STOP or SHUTDOWN command for the graceful shutdown. I could agree on that. Oh, well. I've written the requirement, so I feel better. You can rank the giants as you see them, Pancho. 8-) -- db The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Signal support
On Wed, 9 Aug 2006 14:10:05 -0400 Alan Altmark said: >On Wednesday, 08/09/2006 at 11:02 MST, "Schuh, Richard" <[EMAIL PROTECTED]> >wrote: >> Maybe on VM it has, but I have found that a clean shutdown of RSCS goes >a long >> way toward preventing operational headaches when trying to reconnect to >z/OS or >> MVS systems. Before I created a SHUTDOWN EXEC that tells RSCS to >SHUTDOWN >> QUICK, many of our MVS systems would have to drain the link and restart >it. >> Sometimes, there were time dependencies - a link would have to be >drained on >> both the MVS system and on VM; then the start order needed to be VM >first, JES >> next. Following the SHUTDOWN QUICK, we have only one problem link and it >is >> consistent. It does start after about 15 minutes. > >I'm not sure that you're aren't describing a bug somewhere, but is it >technical problem that you say can be reasonably avoided by orderly >shutdown. So I'd say: write up an RSCS requirement to support signal >shutdown. It may be a bug, but it's a persistent bug. We've had the "problem" for years. Therapy helped, as did banging our heads on the concrete wall outside. We finally settled on Netview automation on the MVS side to look for the problem, drain and restart the link. A lot less blood on the floor. /ahw > >Alan Altmark >z/VM Development >IBM Endicott
Re: Signal support
> Or at all? "No worries, mate. Just shutdown your > system. Everything will be ok. Sleep tight." Ah, but how does the system guarantee this to be the case without a consistently applied methodology of how things start and terminate? In the current setup, you can *guess* that it happened OK, but can you provide a contractual guarantee that the system will be OK? I don't think so. Consider the difference between "kill -HUP" and "kill -TERM". > (Note to self: see if > that gecko is looking to make a change. He would be good at this.) Check out the new Novell partner ad cards. The ninja gecko card is pretty cool. 8-) > Consistency? WDNNSC. NJE signon/signoff has been tolerating the > unexpected loss and reappearance of the remote host for decades. Link setup and connection, yes. The RSCS supervisor itself always had a clean initiation and termination process (I no longer have a RSCS v1 instance, but RSCS v2 certainly did anyway). Note that RSCS is also responsible for cleanly shutting down whatever tasks it started to avoid making GCS sick...8-) It may not matter in the context of a entire system shutdown, but it's still illustrative of good behavior. > RACF, > RSCS, SFS, and TCP/IP don't *need* shutdown. I guess I've repaired one too many corrupted RACF databases to buy that RACF doesn't need a clean shutdown to reliably operate, especially in shared database mode. And had one too many hung I/Os on TCPIP userids. And one too many corrupted SFS catalogs. I'll give you the benefit of the doubt that this may have all been fixed in new releases, but every one of those things is a guaranteed level 3 support call that'll haul you (or someone you have to face every day) out of bed at 2 AM. Wouldn't it be simpler to just prevent them in a way that would avoid the problem entirely? > Dave was right, IMO: It > would be nice, but there's no technical requirement for it. I'd rather > not introduce complexity and delay without benefit. (Believe me, I like > the symmetry of a system shutting down the opposite way it came up. > Therapy is helping.) ??? How does this *increase* complexity, and for whom? If CP SEND TCPIP #CP EXT does what we want it to do, how does causing SIGNAL TCPIP SHUTDOWN to do the same thing make that any worse? It certainly *decreases* complexity for the user -- no "use SIGNAL SHUTDOWN to stop everything, except for these things which use X, and these which use Y, and these ones over here which don't have any shutdown command...". > The LPAR deactivation signal was designed to allow *operating systems* to > flush cache, checkpoint and bring themselves down as quickly as possible. Isn't that what we're doing here? RSCS is a task running in a GCS-based OS. CMS MT is arguably a single user OS. Etc. > It really wasn't meant to be a leisurely > stroll so that all the apps that haven't needed it in the prior century > can all of a sudden wave Goodbye. So make the SIGNAL handler do the equivalent of Z NET,QUICK, and put in a regular STOP or SHUTDOWN command for the graceful shutdown. I could agree on that. Oh, well. I've written the requirement, so I feel better. You can rank the giants as you see them, Pancho. 8-) -- db
Re: Signal support
On Wednesday, 08/09/2006 at 11:02 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Maybe on VM it has, but I have found that a clean shutdown of RSCS goes a long > way toward preventing operational headaches when trying to reconnect to z/OS or > MVS systems. Before I created a SHUTDOWN EXEC that tells RSCS to SHUTDOWN > QUICK, many of our MVS systems would have to drain the link and restart it. > Sometimes, there were time dependencies - a link would have to be drained on > both the MVS system and on VM; then the start order needed to be VM first, JES > next. Following the SHUTDOWN QUICK, we have only one problem link and it is > consistent. It does start after about 15 minutes. I'm not sure that you're aren't describing a bug somewhere, but is it technical problem that you say can be reasonably avoided by orderly shutdown. So I'd say: write up an RSCS requirement to support signal shutdown. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Alan Altmark > Sent: Wednesday, August 09, 2006 10:23 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Signal support > > > > Consistency? WDNNSC. NJE signon/signoff has been tolerating the > unexpected loss and reappearance of the remote host for > decades. RACF, > RSCS, SFS, and TCP/IP don't *need* shutdown. Dave was right, > IMO: It Maybe on VM it has, but I have found that a clean shutdown of RSCS goes a long way toward preventing operational headaches when trying to reconnect to z/OS or MVS systems. Before I created a SHUTDOWN EXEC that tells RSCS to SHUTDOWN QUICK, many of our MVS systems would have to drain the link and restart it. Sometimes, there were time dependencies - a link would have to be drained on both the MVS system and on VM; then the start order needed to be VM first, JES next. Following the SHUTDOWN QUICK, we have only one problem link and it is consistent. It does start after about 15 minutes. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: Signal support
On Wednesday, 08/09/2006 at 11:09 AST, David Boyes <[EMAIL PROTECTED]> wrote: > I'd be more inclined to accept that argument here if they hadn't added > the shutdown support to SFS. We didn't do it for esthetic reasons, but on the assertion that SFS has state information that it needs to save to avoid corrupted disks. We subsequently decided that SFS is, in fact, NOT in any danger when taken down hard, but that doesn't affect the original rationale. > To some extent, that argues (at least to > me) that use of SIGNAL SHUTDOWN is the desired/preferred method for > signaling termination of major subsystems. VM TCPIP is (IMHO) one of the > few IBM-supported non-Linux-based hypervisor support subsystem left on > VM ( in my mind, the majors are TCP/IP, SFS, RACF/clones and RSCS). > There is a way to implement a clean shutdown for TCPIP, but it's fairly > arcane (see below). I know if I were a newbie, #CP EXT wouldn't be > something I'd ever figure out on my own. But why should you have to shutdown your security and communications subsystems separately? Or at all? "No worries, mate. Just shutdown your system. Everything will be ok. Sleep tight." (Note to self: see if that gecko is looking to make a change. He would be good at this.) > There's also an operational consistency perception issue here to combat. > In VM's new (old) role as a hypervisor-only environment, the amount of > CMS knowledge assumed to be available to an admin is minimal. All the > other elements of the base system shut down when presented with a SIGNAL > SHUTDOWN or have a clearly defined shutdown capability -- Linux guests, > RSCS, RACF, SFS, etc. Why is TCP/IP different? And, moreover, why is it > a particularly arcane version of different? It seems a rather glaring > inconsistency. We get dinged majorly for that in the outside world, > where even the Linux cowboys have finally gotten the point that > Consistent Behavior Is Good if you want to survive in the big leagues. Consistency? WDNNSC. NJE signon/signoff has been tolerating the unexpected loss and reappearance of the remote host for decades. RACF, RSCS, SFS, and TCP/IP don't *need* shutdown. Dave was right, IMO: It would be nice, but there's no technical requirement for it. I'd rather not introduce complexity and delay without benefit. (Believe me, I like the symmetry of a system shutting down the opposite way it came up. Therapy is helping.) The LPAR deactivation signal was designed to allow *operating systems* to flush cache, checkpoint and bring themselves down as quickly as possible. We wanted to avoid Linux fsck's on their EXT2 filesystems. (Now folks have moved to ext3. Harrumph.) It really wasn't meant to be a leisurely stroll so that all the apps that haven't needed it in the prior century can all of a sudden wave Goodbye. > Plenty of other windmills to tilt at. 8-) There is never a lack of windmills, Sr. Quixote. :-) Alan Altmark z/VM Development IBM Endicott
Re: Signal support
FWIW, You could also send the TCPIP stack a "CP SEND CP TCPIP EXT" command when it's ready to come down. Alan Altmark <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 08/09/2006 09:23 AM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support On Wednesday, 08/09/2006 at 07:55 AST, David Boyes <[EMAIL PROTECTED]> wrote: > I'll write a requirement for WAVV. Should be simple enough to implement > -- the stack shutdown logic is already there in the external interrupt > handler that is managing the #CP EXT response now; it'd just have to > register for SIGNAL processing and branch to the existing shutdown > routines when it gets the magic signal. I hate to spoil the fun, be we just rejected that requirement a couple of weeks ago. Neither the stack nor the applications maintain state that necessitates an orderly shutdown. Just force them off, stack first. (Else the stack will restart the apps! I *hate* when that happens!) If you really must have orderly shutdown, then get SHUTTRAP and modify it to just issue a message when the signal is received. That message would be picked up by system automation tools that could proceed with NETSTAT CP EXT. After forcing/terminating the application servers, the automation would CP SEND CP TCPIP LOGOFF. (Note that NETSTAT no longer functions after the first EXT.) Use the same technique with DB2 or any other stateful app. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
I'd be more inclined to accept that argument here if they hadn't added the shutdown support to SFS. To some extent, that argues (at least to me) that use of SIGNAL SHUTDOWN is the desired/preferred method for signaling termination of major subsystems. VM TCPIP is (IMHO) one of the few IBM-supported non-Linux-based hypervisor support subsystem left on VM ( in my mind, the majors are TCP/IP, SFS, RACF/clones and RSCS). There is a way to implement a clean shutdown for TCPIP, but it's fairly arcane (see below). I know if I were a newbie, #CP EXT wouldn't be something I'd ever figure out on my own. There's also an operational consistency perception issue here to combat. In VM's new (old) role as a hypervisor-only environment, the amount of CMS knowledge assumed to be available to an admin is minimal. All the other elements of the base system shut down when presented with a SIGNAL SHUTDOWN or have a clearly defined shutdown capability -- Linux guests, RSCS, RACF, SFS, etc. Why is TCP/IP different? And, moreover, why is it a particularly arcane version of different? It seems a rather glaring inconsistency. We get dinged majorly for that in the outside world, where even the Linux cowboys have finally gotten the point that Consistent Behavior Is Good if you want to survive in the big leagues. In any case, it cost about 15 minutes to write the new requirement. If it's wasted effort, I'll live. Plenty of other windmills to tilt at. 8-) -- db
Re: Signal support
On Wednesday, 08/09/2006 at 04:23 ZE2, Kris Buelens <[EMAIL PROTECTED]> wrote: > But Alan, I think I do see a real showstopper: > If one issues CP FORCE myserver > - Myserver gets the signal via SHUTTRAP > - Myserver however cannot make a difference between >- FORCE myserver >- SHUTDOWN > for case 1, it must stop itself only, for case 2 it must stop others and > itself. > > So please, tell me how myserver can differenciate. > I see one thing, that may nearly answer my question: issue CP Q SIGNAL > SHUTDOWN; when all those registered users are ending, we can suppose there is a > shutdown. But, it is only SUPPOSE, nothing certain. You are correct. The signal architecture does not differentiate between LPAR deactivation, SHUTDOWN, FORCE, or LOGOFF. Having support in myserver is because *myserver* needs to do something special to preserve state, and it doesn't matter *why* it is being terminated. This is why my suggestion is not for a common single server to use SHUTTRAP to stop a bunch of other servers. Instead, each server yells "STOP ME" and waits for the auto-op to do it. The auto-op uses SHUTTRAP for its own purposes, specifically to delay the implicit FORCE while it is handling the shutdown (and SEND CP LOGOFF) of other guests. So, if you FORCE an individual guest, only that guest's shutdown procedure is invoked. If it's a SHUTDOWN, they all get invoked. If there is a dependency relationship, then you SHUTTRAP only the *first* server and let the auto-op sequence the shutdown of the others in the relationship. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Gang, I *think* the point Alan is trying to make here is that while it would be *nice*, at least from an aesthetics point of view, to have the TCP/IP stack and it applications support a graceful type of shutdown process, there is no *technical* reason for such a process. No need for TCP/IP stack to use SHUTTRAP. Just kill the stack and then kill the apps, or let CP do it if you're doing a CP SHUTDOWN. Would you rather have this or something new added to VM? DJ Kris Buelens wrote: But Alan, I think I do see a real showstopper: If one issues CP FORCE myserver - Myserver gets the signal via SHUTTRAP - Myserver however cannot make a difference between - FORCE myserver - SHUTDOWN for case 1, it must stop itself only, for case 2 it must stop others and itself. So please, tell me how myserver can differenciate. I see one thing, that may nearly answer my question: issue CP Q SIGNAL SHUTDOWN; when all those registered users are ending, we can suppose there is a shutdown. But, it is only SUPPOSE, nothing certain. Kris, IBM Belgium, VM customer support Alan Altmark <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 2006-08-09 15:23 Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support On Wednesday, 08/09/2006 at 07:55 AST, David Boyes <[EMAIL PROTECTED]> wrote: I'll write a requirement for WAVV. Should be simple enough to implement -- the stack shutdown logic is already there in the external interrupt handler that is managing the #CP EXT response now; it'd just have to register for SIGNAL processing and branch to the existing shutdown routines when it gets the magic signal. I hate to spoil the fun, be we just rejected that requirement a couple of weeks ago. Neither the stack nor the applications maintain state that necessitates an orderly shutdown. Just force them off, stack first. (Else the stack will restart the apps! I *hate* when that happens!) If you really must have orderly shutdown, then get SHUTTRAP and modify it to just issue a message when the signal is received. That message would be picked up by system automation tools that could proceed with NETSTAT CP EXT. After forcing/terminating the application servers, the automation would CP SEND CP TCPIP LOGOFF. (Note that NETSTAT no longer functions after the first EXT.) Use the same technique with DB2 or any other stateful app. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
> I hate to spoil the fun, be we just rejected that requirement a couple of > weeks ago. Neither the stack nor the applications maintain state that > necessitates an orderly shutdown. Just force them off, stack first. (Else > the stack will restart the apps! I *hate* when that happens!) First principle of reliable automation is known states at start and finish, with clearly defined transitions between states, signaled by unambiguous communications between manager and managed task. We have a clear state at initialization, and clear startup messages, but no clear transition to service shutdown. Clearly at some point in the past, there was a need for a clean shutdown and cleanup of what you're doing; otherwise the #CP EXT code wouldn't be there. Modifying it to catch the architected signal and do the same thing instead of faking it with a SHUTTRAP-based kludge is the Right Thing to Do. > If you really must have orderly shutdown, then get SHUTTRAP and modify it > to just issue a message when the signal is received. That message would > be picked up by system automation tools that could proceed with NETSTAT CP > EXT. After forcing/terminating the application servers, the automation > would CP SEND CP TCPIP LOGOFF. (Note that NETSTAT no longer functions > after the first EXT.) Hate to say it, Chuckie, but that's a gross hack. Having application servers fail and die because the stack is shutting down -- especially servers that the stack ORIGINALLY STARTED -- is bad form. To that extent, the TCPIP stack DOES maintain state -- you just said that if you kill the subsidiary servers, then TCPIP will attempt to restart them. Sounds like state to me. -- db
Re: Signal support
Doesn't SHUTTRAP require an assembler? Will ASSEMBLE actually work with it or will it require HLASM? If the latter, then some percentage of sites will not be able to do this. At several hundred dollars a month, it is typically not considered a necessity. Perhaps the request (not a requirement, since this is marketing) should be expanded to include HLASM much like TCP/IP currently is. Alan Altmark wrote: On Wednesday, 08/09/2006 at 07:55 AST, David Boyes <[EMAIL PROTECTED]> wrote: I'll write a requirement for WAVV. Should be simple enough to implement -- the stack shutdown logic is already there in the external interrupt handler that is managing the #CP EXT response now; it'd just have to register for SIGNAL processing and branch to the existing shutdown routines when it gets the magic signal. I hate to spoil the fun, be we just rejected that requirement a couple of weeks ago. Neither the stack nor the applications maintain state that necessitates an orderly shutdown. Just force them off, stack first. (Else the stack will restart the apps! I *hate* when that happens!) If you really must have orderly shutdown, then get SHUTTRAP and modify it to just issue a message when the signal is received. That message would be picked up by system automation tools that could proceed with NETSTAT CP EXT. After forcing/terminating the application servers, the automation would CP SEND CP TCPIP LOGOFF. (Note that NETSTAT no longer functions after the first EXT.) Use the same technique with DB2 or any other stateful app. Alan Altmark z/VM Development IBM Endicott -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: Signal support
>(I *hate* touchpads -- can't figure out how to turn the bloody thing off permanently. It hit send too soon.) Going back to my earlier rant about the foobar Scroll Lock key, someone suggested prying off the keycap (which I did even on the laptop, leaving a stub that still works when I need to turn Num Lock off after having left it enabled it from the external keyboard). Now I know you can't really pry off the touchpad (at least not without substantial damage to the laptop). But someone once suggested to me that one could tape a stiff piece of plastic over it - maybe add something on top of that like "If found, once done filching all the software and personally identifying information, and credit card numbers from this laptop, please contact xyz". Not elegant, not high-tech, but very effective. And it still leaves everything working when you decide to sell or donate the old laptop. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 08/09/2006 05:56 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support > TCP/IP does it need singal support? It doesn't need to close anything, or am I wrong? (I *hate* touchpads -- can't figure out how to turn the bloody thing off permanently. It hit send too soon.) Unless something has changed in 5.2, the TCPIP stack applications that consume stack services all have a way to do clean shutdowns, but the stack itself does not. This has been a lingering remnant of the old FAL 1.0 IP stack code since the beginning - it's probably not critical, but it is annoying that the only way to shut down the stack is CP FORCE or sending it an external interrupt via SCIF, essentially crashing it -- which has occasionally left some network interfaces in unpleasant pending I/O states (especially some of the older interfaces that used continuous channel programs for efficiency). I mean, really, *VTAM* has clean shutdown capabilities. Gotta keep up with the neighbors, ya know. 8-) -- db The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Signal support
But Alan, I think I do see a real showstopper: If one issues CP FORCE myserver - Myserver gets the signal via SHUTTRAP - Myserver however cannot make a difference between - FORCE myserver - SHUTDOWN for case 1, it must stop itself only, for case 2 it must stop others and itself. So please, tell me how myserver can differenciate. I see one thing, that may nearly answer my question: issue CP Q SIGNAL SHUTDOWN; when all those registered users are ending, we can suppose there is a shutdown. But, it is only SUPPOSE, nothing certain. Kris, IBM Belgium, VM customer support Alan Altmark <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 2006-08-09 15:23 Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support On Wednesday, 08/09/2006 at 07:55 AST, David Boyes <[EMAIL PROTECTED]> wrote: > I'll write a requirement for WAVV. Should be simple enough to implement > -- the stack shutdown logic is already there in the external interrupt > handler that is managing the #CP EXT response now; it'd just have to > register for SIGNAL processing and branch to the existing shutdown > routines when it gets the magic signal. I hate to spoil the fun, be we just rejected that requirement a couple of weeks ago. Neither the stack nor the applications maintain state that necessitates an orderly shutdown. Just force them off, stack first. (Else the stack will restart the apps! I *hate* when that happens!) If you really must have orderly shutdown, then get SHUTTRAP and modify it to just issue a message when the signal is received. That message would be picked up by system automation tools that could proceed with NETSTAT CP EXT. After forcing/terminating the application servers, the automation would CP SEND CP TCPIP LOGOFF. (Note that NETSTAT no longer functions after the first EXT.) Use the same technique with DB2 or any other stateful app. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Perhaps one might want to hold off a shutdown while an existing FTP session completes? Esp. considering the recent thread on Ftp'ing large dumps to vendors. One can always override the shutdown more emphatically if the FTP is getting in the way of an urgently needed shutdown. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 08/09/2006 05:35 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support Unless something has changed in 5.2, the TCPIP stack applications have a way to do clean shutdowns, but the stack itself does not. This has been a lingering remnant of the old IP stack code since the beginning ? it?s probably not critical, but it is annoying that the only way to shut down the stack is CP FORCE or sending it an external interrupt, essentially crashing it. TCP/IP does it need singal support? It doesn't need to close anything, or am I wrong? The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Signal support
> Is it too late to write one for SHARE next week? A WAVV requirement > won't be received until late next May. Up to someone involved with SHARE to do that. Can't hurt to have it come from more than one source, though. Turned out to be a very quick one to write. I've submitted requirement WRIBDB01 to WAVV this morning. Copy of the requirement text submitted available at http://www.sinenomine.net/node/561 (if you have trouble opening the file directly, save it to disk and open it from there -- apparently MS has broken direct viewing somehow on people's Windows boxen who still use IE). (In passing, I also created OpenOffice versions of the WAVV requirements template and sent them along to WAVV. If you want a copy, contact WAVV). -- db
Re: Signal support
On Wednesday, 08/09/2006 at 07:55 AST, David Boyes <[EMAIL PROTECTED]> wrote: > I'll write a requirement for WAVV. Should be simple enough to implement > -- the stack shutdown logic is already there in the external interrupt > handler that is managing the #CP EXT response now; it'd just have to > register for SIGNAL processing and branch to the existing shutdown > routines when it gets the magic signal. I hate to spoil the fun, be we just rejected that requirement a couple of weeks ago. Neither the stack nor the applications maintain state that necessitates an orderly shutdown. Just force them off, stack first. (Else the stack will restart the apps! I *hate* when that happens!) If you really must have orderly shutdown, then get SHUTTRAP and modify it to just issue a message when the signal is received. That message would be picked up by system automation tools that could proceed with NETSTAT CP EXT. After forcing/terminating the application servers, the automation would CP SEND CP TCPIP LOGOFF. (Note that NETSTAT no longer functions after the first EXT.) Use the same technique with DB2 or any other stateful app. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Is it too late to write one for SHARE next week? A WAVV requirement won't be received until late next May. David Boyes wrote: I'll write a requirement for WAVV. Should be simple enough to implement -- the stack shutdown logic is already there in the external interrupt handler that is managing the #CP EXT response now; it'd just have to register for SIGNAL processing and branch to the existing shutdown routines when it gets the magic signal. Should have a draft ready later today. -- db -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: Signal support
> #cp ext does not crash the stack, but is picked up as a signal to stop > the stack. Sorry -- meant crash in this case that there is no explicit shutdown command (other than this somewhat obscure use of the external interrupt command). Thanks for the clarification. > My understanding is that from that point the stack does not > accept new connections but continues to run the open ones and give > them time to close. I suppose this might make sense to complete a > current ftp transfer or web transaction. > So it might make sense to have TCPIP understand a signal shutdown like > that. If the sessions don't close all before the signal expired, CP > will take the virtual machine down. Would work. I'll write a requirement for WAVV. Should be simple enough to implement -- the stack shutdown logic is already there in the external interrupt handler that is managing the #CP EXT response now; it'd just have to register for SIGNAL processing and branch to the existing shutdown routines when it gets the magic signal. Should have a draft ready later today. -- db
Re: Signal support
On 8/9/06, David Boyes <[EMAIL PROTECTED]> wrote: Unless something has changed in 5.2, the TCPIP stack applications have a way to do clean shutdowns, but the stack itself does not. This has been a lingering remnant of the old IP stack code since the beginning – it's probably not critical, but it is annoying that the only way to shut down the stack is CP FORCE or sending it an external interrupt, essentially crashing it. #cp ext does not crash the stack, but is picked up as a signal to stop the stack. My understanding is that from that point the stack does not accept new connections but continues to run the open ones and give them time to close. I suppose this might make sense to complete a current ftp transfer or web transaction. So it might make sense to have TCPIP understand a signal shutdown like that. If the sessions don't close all before the signal expired, CP will take the virtual machine down. Would work. Rob
Re: Signal support
> TCP/IP does it need singal support? It doesn't need to close anything, or am I wrong? (I *hate* touchpads -- can't figure out how to turn the bloody thing off permanently. It hit send too soon.) Unless something has changed in 5.2, the TCPIP stack applications that consume stack services all have a way to do clean shutdowns, but the stack itself does not. This has been a lingering remnant of the old FAL 1.0 IP stack code since the beginning - it's probably not critical, but it is annoying that the only way to shut down the stack is CP FORCE or sending it an external interrupt via SCIF, essentially crashing it -- which has occasionally left some network interfaces in unpleasant pending I/O states (especially some of the older interfaces that used continuous channel programs for efficiency). I mean, really, *VTAM* has clean shutdown capabilities. Gotta keep up with the neighbors, ya know. 8-) -- db
Re: Signal support
Unless something has changed in 5.2, the TCPIP stack applications have a way to do clean shutdowns, but the stack itself does not. This has been a lingering remnant of the old IP stack code since the beginning – it’s probably not critical, but it is annoying that the only way to shut down the stack is CP FORCE or sending it an external interrupt, essentially crashing it. TCP/IP does it need singal support? It doesn't need to close anything, or am I wrong?
Re: Signal support
TCP/IP does it need singal support? It doesn't need to close anything, or am I wrong? DB2/VM: yes, we'd like that too. I plan to have one of our servers (that uses SHUTTRAP) have the DB2 servers to stop. But: - it is hard to know why our REXX server gets a signal: was it a FORCE or a SHUTDOWN? - it cannot protect DB2 against a "CP FORCE db2Sever" So, DB2/VM is indeed one of the products that really could, SHOULD, use Signal support. Kris, IBM Belgium, VM customer support Alan Ackerman <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 2006-08-09 06:41 Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support On the same topic (but not VSE) we have submitted requests (or whatever IBM now calls them) for support by DB2 and TCP/IP of the shutdown signal. Is anyone else interested?
Re: Signal support
On the same topic (but not VSE) we have submitted requests (or whatever I BM now calls them) for support by DB2 and TCP/IP of the shutdown signal. Is anyone else interest ed?
Re: Signal support
If somebody wants to write up a WAVV requirement, I would vote for it. [EMAIL PROTECTED] wrote: This just in... Yes, VSE did briefly add registration for the LPAR deactivation signal (SIGNAL SHUTDOWN), but the implementation was incomplete and created other problems. In particular, VSE doesn't load the "shutdown complete" PSW, causing LPAR deactivation to delay 5 minutes. The support has been removed. If you need the support, work with your fave user group or the Support Center to get a requirement opened. If your need is urgent, you *may* be able to get the enablement fix, but it isn't supported. Those who have the fix already know they are on their own. "And that's the way it is" Alan Altmark z/VM Development IBM Endicott -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Signal support
On Monday, 08/07/2006 at 10:58 EST, "Huegel, Thomas" <[EMAIL PROTECTED]> wrote: > I am waiting breathlessly. Has the highly-placed and respected person at VSE > developement responded, and cleared the air? This just in... Yes, VSE did briefly add registration for the LPAR deactivation signal (SIGNAL SHUTDOWN), but the implementation was incomplete and created other problems. In particular, VSE doesn't load the "shutdown complete" PSW, causing LPAR deactivation to delay 5 minutes. The support has been removed. If you need the support, work with your fave user group or the Support Center to get a requirement opened. If your need is urgent, you *may* be able to get the enablement fix, but it isn't supported. Those who have the fix already know they are on their own. "And that's the way it is" Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Title: RE: Signal support Only breathlessly? EMS had to come to revive my blue-toned face multiple times over the weekend! :) David Wakser From: Huegel, Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 11:58 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: Signal support I am waiting breathlessly. Has the highly-placed and respected person at VSE developement responded, and cleared the air? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Alan Altmark Sent: Thursday, August 03, 2006 11:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 11:30 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > A previous post mentioned that the only way the facility could be > enabled in VSE was through a special PTF that IBM had provided to one customer. > Now the question is: why did he need that PTF? This whole matter seems poorly > documented from the VSE side. A highly-placed and respected person in VSE Development is investigating to find out what's going on. If all goes acccording to plan, I should have an answer tomorrow. BTW, that "previous post" was over in VSE-L. Very confusing. :-) Alan Altmark z/VM Development IBM Endicott __ << ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Signal support
Title: RE: Signal support I am waiting breathlessly. Has the highly-placed and respected person at VSE developement responded, and cleared the air? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Alan Altmark Sent: Thursday, August 03, 2006 11:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 11:30 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > A previous post mentioned that the only way the facility could be > enabled in VSE was through a special PTF that IBM had provided to one customer. > Now the question is: why did he need that PTF? This whole matter seems poorly > documented from the VSE side. A highly-placed and respected person in VSE Development is investigating to find out what's going on. If all goes acccording to plan, I should have an answer tomorrow. BTW, that "previous post" was over in VSE-L. Very confusing. :-) Alan Altmark z/VM Development IBM Endicott __ << ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Signal support
Title: RE: Signal support Alan: Yes, you are correct, this topic seems to "span" lists! David Wakser -Original Message- From: Alan Altmark [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 03, 2006 12:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 11:30 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > A previous post mentioned that the only way the facility could be > enabled in VSE was through a special PTF that IBM had provided to one customer. > Now the question is: why did he need that PTF? This whole matter seems poorly > documented from the VSE side. A highly-placed and respected person in VSE Development is investigating to find out what's going on. If all goes acccording to plan, I should have an answer tomorrow. BTW, that "previous post" was over in VSE-L. Very confusing. :-) Alan Altmark z/VM Development IBM Endicott Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Signal support
On Thursday, 08/03/2006 at 10:44 EST, "McKown, John" <[EMAIL PROTECTED]> wrote: > z/OS is far too arrogant to do anything like looking to see if it is > running under z/VM. There is absolutely NO interface between z/OS and > z/VM. As I said, this is a hardware facility. If the OS registers for it, the signal is generated whenever a disruptive task is being performed against the running partition. And, actually, z/OS does make at least one check for VM: he wants to know whether or not to use "active wait" for his spin locks or to exploit diag 0x44. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
On Thursday, 08/03/2006 at 11:30 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > A previous post mentioned that the only way the facility could be > enabled in VSE was through a special PTF that IBM had provided to one customer. > Now the question is: why did he need that PTF? This whole matter seems poorly > documented from the VSE side. A highly-placed and respected person in VSE Development is investigating to find out what's going on. If all goes acccording to plan, I should have an answer tomorrow. BTW, that "previous post" was over in VSE-L. Very confusing. :-) Alan Altmark z/VM Development IBM Endicott
Re: Signal support
> -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Thursday, August 03, 2006 10:28 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Signal support > I have no idea of z/OS supports the signal or not. > > Alan Altmark > z/VM Development > IBM Endicott > z/OS is far too arrogant to do anything like looking to see if it is running under z/VM. There is absolutely NO interface between z/OS and z/VM. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited.
Re: Signal support
> I have no idea of z/OS supports the signal or not. Empirical results indicate that z/OS 1.7 does not specifically register for SIGNAL SHUTDOWN. We have 3 to 4 z/OS guests running on z/VM 5.2, along with several Linux (SLES9) guests. CP QUERY SIGNALS ALL ALL shows the Linux and SFS servers, but nothing for the z/OS 1.7 guests. Mike Walter Hewitt Associates The comments expressed herein at mine alone, not those of my employer. "Alan Altmark" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 08/03/2006 10:28 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Signal support On Thursday, 08/03/2006 at 11:13 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > We recently moved all our VSE guests from under a VM 2.3 system to z/VM > 5.1 and we did NOTHING to enable it in any VSE - yet ALL VSE machines show up > as SIGNAL enabled! Explanation please? I'm not sure what you want me to explain. VSE is apparently enabling itself, just like CP does, if the facility is available. I have no idea of z/OS supports the signal or not. It is really base hardware support since CP SIGNAL SHUTDOWN is just simulation of the signal generated when you deactivate an LPAR on machines that have the capability. Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Signal support
Title: RE: Signal support Alan: A previous post mentioned that the only way the facility could be enabled in VSE was through a special PTF that IBM had provided to one customer. Now the question is: why did he need that PTF? This whole matter seems poorly documented from the VSE side. David Wakser -Original Message- From: Alan Altmark [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 03, 2006 11:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 11:13 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > We recently moved all our VSE guests from under a VM 2.3 system > to z/VM > 5.1 and we did NOTHING to enable it in any VSE - yet ALL VSE machines show up > as SIGNAL enabled! Explanation please? I'm not sure what you want me to explain. VSE is apparently enabling itself, just like CP does, if the facility is available. I have no idea of z/OS supports the signal or not. It is really base hardware support since CP SIGNAL SHUTDOWN is just simulation of the signal generated when you deactivate an LPAR on machines that have the capability. Alan Altmark z/VM Development IBM Endicott Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Signal support
The supervisor can just execute the SERVC and write the appropriat event mask. If the underlying VM system doesnt support the signal then itll either be a no-op or youll get a return code in the SERVC plist. z/VSE can detect this and ignore the case where VM doesnt support it or take advantage of it if it does. There need not be any human involvement. (VSE could also use DIAG 0 to determine the level of VM it is running on and issue the SERVC if it detects a level that will support the passing of signals.) Neale: Yes, but if something needs to be DONE to enable the guests, yet we did nothing but move them under z/VM 5, how did they become enabled? David Wakser
Re: Signal support
On Thursday, 08/03/2006 at 11:13 AST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > We recently moved all our VSE guests from under a VM 2.3 system to z/VM > 5.1 and we did NOTHING to enable it in any VSE - yet ALL VSE machines show up > as SIGNAL enabled! Explanation please? I'm not sure what you want me to explain. VSE is apparently enabling itself, just like CP does, if the facility is available. I have no idea of z/OS supports the signal or not. It is really base hardware support since CP SIGNAL SHUTDOWN is just simulation of the signal generated when you deactivate an LPAR on machines that have the capability. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
Title: RE: Signal support Neale: Yes, but if something needs to be DONE to enable the guests, yet we did nothing but move them under z/VM 5, how did they become enabled? David Wakser -Original Message- From: Neale Ferguson [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 03, 2006 11:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support VM 2.3 didn't support signals. I think it came in 4.2 or 4.3. Alan: We recently moved all our VSE guests from under a VM 2.3 system to z/VM 5.1 and we did NOTHING to enable it in any VSE - yet ALL VSE machines show up as SIGNAL enabled! Explanation please? Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Signal support
Title: RE: Signal support But none of that was ever done here, yet the VSE guests all show up as SIGNAL enabled! David Wakser -Original Message- From: Neale Ferguson [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 03, 2006 11:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support It's done programmatically. You use the SERVC opcode to write an event mask that has a bit on that says you'll accept a given signal. Your program also needs to setup an external interrupt handler to field the signal when it comes. Have a look at the SHUTTRAP program on the VM Download Library. That was my original question! I cannot seem to find any documentation regarding that. David Wakser Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Signal support
VM 2.3 didnt support signals. I think it came in 4.2 or 4.3. Alan: We recently moved all our VSE guests from under a VM 2.3 system to z/VM 5.1 and we did NOTHING to enable it in any VSE - yet ALL VSE machines show up as SIGNAL enabled! Explanation please?
Re: Signal support
Title: RE: Signal support Alan: We recently moved all our VSE guests from under a VM 2.3 system to z/VM 5.1 and we did NOTHING to enable it in any VSE - yet ALL VSE machines show up as SIGNAL enabled! Explanation please? David Wakser From: Huegel, Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 11:12 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: Signal support Alan any guess as how to enable it in z/VSE or that other OS? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Alan Altmark Sent: Thursday, August 03, 2006 10:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 10:31 AST, "Horlick, Michael" <[EMAIL PROTECTED]> wrote: > From the ?Running Guest Operating Systems? manual: > >> > The QUERY SIGNALS command can be used to determine whether a guest is enabled > to receive shutdown signals. > << > > How does a guest enable oneself for signal support ? A CMS guest uses Romney's SHUTTRAP package from the VM Download library. A Linux guest configures ctrlaltdel in the etc/inittab. Alan Altmark z/VM Development IBM Endicott __ << ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Signal support
Its done programmatically. You use the SERVC opcode to write an event mask that has a bit on that says youll accept a given signal. Your program also needs to setup an external interrupt handler to field the signal when it comes. Have a look at the SHUTTRAP program on the VM Download Library. That was my original question! I cannot seem to find any documentation regarding that. David Wakser
Re: Signal support
Title: RE: Signal support Alan any guess as how to enable it in z/VSE or that other OS? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Alan Altmark Sent: Thursday, August 03, 2006 10:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 10:31 AST, "Horlick, Michael" <[EMAIL PROTECTED]> wrote: > From the ?Running Guest Operating Systems? manual: > >> > The QUERY SIGNALS command can be used to determine whether a guest is enabled > to receive shutdown signals. > << > > How does a guest enable oneself for signal support ? A CMS guest uses Romney's SHUTTRAP package from the VM Download library. A Linux guest configures ctrlaltdel in the etc/inittab. Alan Altmark z/VM Development IBM Endicott __ << ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Signal support
On Thursday, 08/03/2006 at 10:31 AST, "Horlick, Michael" <[EMAIL PROTECTED]> wrote: > From the ?Running Guest Operating Systems? manual: > >> > The QUERY SIGNALS command can be used to determine whether a guest is enabled > to receive shutdown signals. > << > > How does a guest enable oneself for signal support ? A CMS guest uses Romney's SHUTTRAP package from the VM Download library. A Linux guest configures ctrlaltdel in the etc/inittab. Alan Altmark z/VM Development IBM Endicott
Re: Signal support
That was my original question! I cannot seem to find any documentation regarding that. David Wakser From: Horlick, Michael [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 10:32 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Signal support How does a guest enable oneself for signal support ? Thanks Mike Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
