Here is what I did this morning: The chain of pids under pid=1 looked like this 1--> 400 (userid3) --> 200 (userid5) --> 500 (userid1) --> 300 (userid5) and so on.
c userid*.* (there was no address space without a number at the end) got me: IEE535I CANCEL INVALID PARAMETER c userid.* (not that I expected this to work): IEE341I userid.* NOT ACTIVE So I ended up displaying the pids and forcing the one right below pid=1. f bpxoinit,force=400 got rid of that process and changed the chain to 1--> 200 (userid5) --> 500 (userid1) --> 300 (userid5) and so on. There were 7 pids left, and the last two went away together. >F OMVS,SHUTDOWN well, at the point I detected those pids, issuing this command would have been just as bad as what I did (shutting down the fork service), as OMVS (or the fork service) was still needed for WBI shutdown. And thank goodness we're not using shared HFS! >Of course automation tries to take things down in the correct order first >to eliminate unix processes and then displays them at the end and >tries to get rid of any stragglers if they exist, but 'F OMVS,SHUTDOWN' >is still the last thing done. I am concerned with the case where some sort of 'forgotten' process makes shutdown of another subsystem (like IMS, like DB2, like MQS, ....) impossible because for normal shutdown they all tend to wait for running things to complete. Except *these* running things will never terminate. So we never get around to our catch-all automation clist that terminates the stragglers. We ahd shutdown hang itself up because DB2 wouldn't shut down, and then a long discussion occured if we can use the stop mode(force) on DB2. We had a similar discussion when some sort of error prevented WBI from shutting down and hence MQS from shutting down. >The suggestion received strong disapproval because >so many address spaces nowadays get dubbed inadvertently and >would suffer badly from an unexpected and uncaught SIGTERM. Right. Good recovery (MVS style) would always react properly to SIGTERM, so there would never be an 'unexpected' SIGTERM. >So, which to use: STOP, MODIFY, or SIGTERM; and in what order? What frustrates me most is the absence of a command that will terminate a pid chain (like described above) *without* having to issue a force to each and every process. The numbers aren't really conducive to being analyzed by a human, terminating them in no particular order usually results in them multiplying all over again. Even putting what I did into a clist (always terminating the top pid, right under pid1) is no guarantee that *some* sort of recovery will not go and build the while tree again with new pids faster than I can issue the termination commands, even via automation. Oh well, thanks to all who supplied their own shutdown procedures.... 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
