>Programming-wise, we should make sure that STOP never gets us into a stupid >"waiting for TCP/IP to come up" situation. Other than that sort of thing, is >there anything else we should be doing relative to shutdown and >dependencies?
It is even worse than 'waiting for TCPIP to come up'. You have to make sure that TCPIP is available when you shut down (and TCPIP could have abended) *if* you need IP services to do the shutdown. You have to have a way to still come down gracefully in case the needed services aren't available. And you have to make sure that you realize that either TCPIP has abended or OMVS has been mangled and terminate yourself. One ftp product (whose company has recently been bought by IBM) sleeps through a tcpip restart and is completely hung when IP comes back up. That should not happen either. These days TCPIP will not shut down (AFAIK) if IP knows about something (listeners, maybe - I am not IP literate). Just like OMVS will not shutdown if anyone requested it to not honour the shutdown command (which DB2 and TCPIP both do as of 1.10, I think - which in turn makes the OMVS shutdown command completely useless, AFAIAC). >It's easy to feel beat-up here no matter what you say or do. If that is because of something I said, I apologize. *That* was certainly not my intention! >This is great. This should be required reading for every vendor. (the above then cites Linda points). Actually, IBM is as guilty as any vendor of NOT documenting things properly. And Charles, if you work through Lindas list, please add the WLM stuff I had also mentioned. In your case it will be an STC that is (slightly) lower than TCPIP and any other service giver fot your STC - the rest should be figured out by whoever maintains the WLM policy. >While I'm on a rant here you in the sysprog community should keep in mind >that you are not the entire audience for our products. Are you saying that the people buying your product are actually *reading* installation instructions?!? That would really amaze me, as installation instructions tend to be highly technical, and the people in charge of spending money usually don't have a clue of the actual *technical* content and wouldn't (usually) touch such a book with a ten-foot-pole! >>Setting this up as a >>started task and then explaining to Ops/Automation that the only way to >>stop it was to Cancel the Started task was not fun (against their >>operational procedures) .... >Shutting down a Started Task can be done in the way other STCs are >controlled. You can issue a WTOR which allows the request to shut >down to be sent or you can just use the Modify (F) or STOP (P) >command . If MODIFY is good enough for TCP, TSO, etc, it should be >good enough for your RYO STC. It sounds like those Ops/Automation >types are brain dead and do not understand what they are doing. No, I don't think so. MODIFY can easily tie up the CSCB for the address space, and then you get some sort of error message when you retry any command. There needs to be programming done to prevent this. And a cancel can also easily have been mandatory when the stop command was accepted, but the address space just goes to sleep waiting for something that will never happen. The next stop has no effect. So you have to cancel. You obviously have never been in the situation where you stop and things hang, you stop again, nothing happens. You cancel, the thing says 'cancel command accepted' and then it hangs again. You try force and are told that you haven't force arm'd first. You try force arm and are told that you cannot force arm the asid. Or you get another hang. In your desperation you dump the address space and then assemble the callrtm program with different tcbs in hopes that it will go. Best 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
