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