>Yes. This sounds like APARable behavior. Unless they designed >the server to purposefully hang.
:-) Broken as designed? >I'm sort of surprised that anything in TCP/IP worked after a restart >of OMVS, and I'm not surprised that different parts failed (or not) >in different ways. There must have been timing dependant failures >all over the place. What I expect when I terminate OMVS in full flight is that every address space that cannot survive without these BPX services also terminates. There were three or four exceptions to it: 1. One of the DB2 asids said immediately that it will block shutdown. *That* address space I was able to terminate successfully using normal shutdown commands from automation. Then I re-issued the F OMVS,shutdown command. 2./3. At this point two of the three TN3270 asids (which I sloppily call 'telnet address spaces', mostly for lack of knowledge in the TCPIP area) said that *they* are blocking OMVS shutdown. I attempted to use automation to get them to terminate. This failed miserably as they apparently need *something* from OMVS while terminating which did not work anymore. I had to force them down. 4. The third TN3270 asid gave an indication that it terminates, but it didn't. It also did not block shutdown like the other two did. OMVS simply took down everything else, I issued the F OMVS,restart command and then (via automation) restarted everything that had terminated during the OMVS shutdown. That third TN3270 appeared unaffected for about a week. *Then* a colleague needed those services and it turned out that basically *nothing* worked in there. Abend202 posting an ECB that had gone eons earlier when that address space was shut down. (At least it terminated without force.) >Does IBM claim that TCP/IP and its associated bits and pieces can >survive the loss and restart of OMVS? If so, they should make it >work. No, IBM doesn't claim that. If any claim is made then that the address spaces relying on OMVS will terminate when OMVS goes away. I seem to remember a post from Jim Mulder from years ago that lack of recovery in OMVS exploiters was what prohibited IBM from making OMVS restartable. Given that the shutdown/restart command is now possible, *I* as a customer expect the IBM exploiters of BPX services to have recovery in place that detects OMVS going away (there is a kind of exit that gets called when OMVS receives the shutdown command. I am assuming that is what DB2 uses to 'block' shutdown). And I expect every address space that cannot live without OMVS to go away, too. In my opinion, it is definitely incorrect (and aparable) when TN3270 asid a) sleeps through shutdown but doesn't work afterwards) b) cannot be terminated cleanly anymore. We did not do the OMVS shutdown excercise just for fun, we did have a semi- production problem where we weren't sure if an IPL was required. Given that most of our work is IMS, an OMVS restart would have been preferable to a during-the-day-IPL, with less downtime. And as time was at a premium, I much rather 'fix' automation stati after an OMVS restart than wait for orderly shutdown. Some of those OMVS exploiters (WAS comes to mind) take about 20 minutes to come down. After the OMVS restart, with the exception of that one TN3270 *everything* worked again. So that one TN3270 must behave like the others - either 'block' shutdown or come down cleanly, too. (Actually, they all MUST respond to a shutdown command, which they did not.) I only remember one address space living through the restart, and that was Automation Netview. It complained, withdrew its feet from OMVS, but did not terminate. Regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
