> 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
