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
|
|
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
