Think about what FORCE does in terms of cleanup and in relation to cancel and force arm:
Cancel will attempt to terminate (callrtm) the first application tcb in an address space. That tcb is responsible for terminating its daughters. During that processing, *all* established end-of-task routines *and* task termination resource managers are given control. Usually, when the address space doesn't come down after cancel, something is wrong with one of them in the first place, so further cancels don't have much effect. I am a bit fuzzy on force arm, but I think force arm still ensures that task termination resource managers are given control. (I am sure someone will correct me if I'm wrong.) Both of those run in the address space to be canceled with full access to all private storage. Both of those are supposed to allow for full cleanup of all resources (be it latches, enqs, common storage). In addition, during address space termination 'the system' does a lot of 'forgotten cleanup' for an address space: Definitely all private storage, local locks, latches and ENQs held in that address space. At the end of that, there is a memterm task attached in master, and that will take care of the rest (memterm resource managers). Now FORCE is another matter entirely. First of all, the FORCE command does NOT run in the address space, it runs in MASTER address space and cannot access the private storage of the address space any more. All it attempts is to run the established *memterm* resource managers that the address space has, including some that belong to 'the system'. (For instance, no matter if a TSO user had used RRS, an RRS memterm resource manager is established for every address space in the system and gets control.) The warning in the book is there for a reason: When a memterm resource manager cannot access a 'local' resource anymore (maybe because the address pointing to the common storage describing that resource was lost/invalidly freemained before the common storage could get freemained/clobbered by some bug), then that resource (usually needed for a restart) is not cleaned up. And if the address space forced is sufficiently important, you IPL. Finally, I can provide two war stories with force: 1. HFS mount latch held in OMVS address space (back when OMVS wasn't restartable) due to a known new bug in HFS/PDSE code. The address space that had initated OMVS getting the mount latch was forced out. Latch still held. Now, without the mount latch all HFS activity grounds to a halt - no logon, no file access for new files. They all queue themselves behind. Did I mention this was production? I took a dump and determined which tcb in OMVS held the latch. Then I told my boss 'I can attempt to terminate that tcb, but if it goes wrong we must IPL. If I don't attempt it, we must IPL.' Well, the little callrtm program terminated the tcb holding that latch, so everyone could go on. *Then* I had a hard time to initiate an IPL for that system to clean up all maybe outstanding problems that I might have caused. (I think these days that has even become an 'official' OMVS command with the appropriate warning.) 2. IMS. To preserve integrity, IMS protects its BMPs from being forced/canceled/whatever. The only supported way to get rid of a hung BMP (usually a TSO user that does expediter testing and that did not heed the many abend878/80A that it already had) is to use an IMS command to terminate it. Every once in a while, IMS tells us in response to that command that there is no such BMP, but the address space did not go away. They try cancel: 'non-cancelable, use force arm', then they try force arm: 'you must use cancel first' (how am I supposed to do that?!?). Then they call me to see if the little callrtm program can do the trick. It used to, but for the last two occurances it didn't anymore. Result is a restart of IMS. In this installation there is a definite NONO to use the FORCE command. Only sysprogs are supposed to use it, and then only a handful and after due deliberation. Thanks for reading through all this! Regards, Barbara -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ---------------------------------------------------------------------- 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
