Re: Telnet, was: Re: USS misuse
Barbara No USS in my post! It was my intention to change the Subject line to your new one - but I forgot! Sorry. There are some subject line policemen out there of whom we need to be wary! Chris Mason On Mon, 10 Aug 2009 01:04:08 -0500, Barbara Nitz nitz-...@gmx.net wrote: ... only the above is relevant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Telnet, was: Re: USS misuse
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Telnet, was: Re: USS misuse
On Fri, 7 Aug 2009 00:05:02 -0500, Barbara Nitz nitz-...@gmx.net wrote: What did NOT come down were the three corresponding telnet address spaces. This was by design. (Not just working as designed.) But that's not true! When OMVS starts to go away, without *any* stop or other command the telnet address spaces *do* start terminating! Ah! I misunderstood and so my comment was not relevant. The working as designed part was the Tn3270 server staying up if the stack goes down. I don't know what the appropriate behavior if OMVS goes down (or starts to go down). There must be some sort of provision, apparently it just wasn't tested, much less fixed. ... That's just my point: We are not talking 'broken as designed' here, we are talking BUG here, which IBM normally even fixes via ptf! Yes. This sounds like APARable behavior. Unless they designed the server to purposefully hang. ... 2. In a multi-stack environment access to Tn3270 may still be available through another stack. (I did not hear this justification from IBM and have never worked in a multi-stack environment so I don't know if that explanation holds water.) Aha, where did you hear that? ... I think it was a discussion at SHARE, but since I have never been in a multi-stack environment (multi-stack on one LPAR, that is), I didn't pay much attention. Interestingly enough, IBM support hasn't told me that the third telnet asid NOT coming down was by design, too! :-) The third one also started to terminate, but never 'blocked' OMVS shutdown, so it remained up in half-terminated state throughout OMVS restart, and obviously didn't really work afterwards. 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. 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. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Telnet, was: Re: USS misuse
What did NOT come down were the three corresponding telnet address spaces. This was by design. (Not just working as designed.) But that's not true! When OMVS starts to go away, without *any* stop or other command the telnet address spaces *do* start terminating! There must be some sort of provision, apparently it just wasn't tested, much less fixed. The responses of the three telnet address spaces we have varied wildly! And they terminate, they just stop midway through termination, no matter what the docs say. That's just my point: We are not talking 'broken as designed' here, we are talking BUG here, which IBM normally even fixes via ptf! 2. In a multi-stack environment access to Tn3270 may still be available through another stack. (I did not hear this justification from IBM and have never worked in a multi-stack environment so I don't know if that explanation holds water.) Aha, where did you hear that? Interestingly enough, IBM support hasn't told me that the third telnet asid NOT coming down was by design, too! :-) The third one also started to terminate, but never 'blocked' OMVS shutdown, so it remained up in half-terminated state throughout OMVS restart, and obviously didn't really work afterwards. That's what started this off: When my colleagues realized it did not work anymore, they attempted to shut it down, and *that* resulted in a dump that IBM immediately told me was due to the fact that OMVS *was coming down*. Well, not true. Since OMVS had been up for about 5 days after the restart, it most definitely was *not* coming down! At which point I was told that we hadn't followed the books. Which are wrong, anyway. And I also got the usual response we've heard a lot on ibm-main: Nobody has ever told us this is a problem (that from development). Stopping here. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
