Barbara and others, Although this email is a little late, a good reference for dependencies at start up and shut down can be found in the MTTR Redbook - http://www.redbooks.ibm.com/abstracts/sg247816.html?Open. Although the TCP/IP issue isn't addressed, there are other dependencies that might be of interest to people following this thread.
Best regards, Cheryl ====================== Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com 941-266-6609 ====================== On Sep 30, 2010, at 12:52 AM, Barbara Nitz wrote: > I disagree on some points in this part of the discussion: This is funny. I don't think you disagreed on anything, just clarified things a bit :-) (I was too much in a hurry yesterday.) > A Brave man !! ... :-) ... uh oh. Seems I need to stop saying anything :-) Not that that is going to stop me :-(. > That is not correct. CANCEL does a POST of the CANCEL ECB, on which the > initiator task is WAITing. The initiator task then does a CALLRTM > TYPE=ABTERM of the jobstep task. Which in turn tries to get its daughter tasks to terminate by issuing the appropriate detach abends to them. At least that's what I remember they should do. And the hang occurs when one of them daughters gets control in their recovery routine and does something stupid like rely on something that just isn't there (anymore - like an ECB that will never be posted anymore because the application supposed to post it has forgotten to do it when *it* terminated) causing our address space to hang indefinitely. In some cases a second cancel helps, but for the past years I haven't seen that to work anymore. And in the case of an IMS MPR/BMP, this point usually means restart of all of IMS (I get involved when IMS doesn't know about the MPR/BMP anymore, but the address space is caught in the cancel/force arm/force loop. At that point I get to try the callrtm program. And the culprit in thise cases has always been Xpediter, and they have been unable to determine what they do wrong to cause an IMS restart at the best online time - every time.) If that situation occured, automation setup and operational procedure were both correct. In fact, we don't want our operators to use cancel unless we tell them to, either. Much less force. Best 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 ---------------------------------------------------------------------- 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
