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 <IBMVM@LISTSERV.UARK.EDU>
2006-08-09 15:23
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
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