Hi Barbara Either from within SDSF with the "PS" panel or from within OMVS and issuing the " ps -ef" are you able to see what the User is executing,
Regards Gerard Ceruti may the 'z' be with you SharePoint (internal) -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: 23 June 2009 11:23 To: IBM-MAIN@bama.ua.edu Subject: And you ask why I hate OMVS? This past weekend I had the dubious honour of shutting down and IPLing 5 systems, two of them with USS work. The shutting down part was really bad (now I know why our operators keep complaining). One lpar has my favourite hate-application running (called WBIFN, for all you European SWIFT customers). Around seven minutes into the shutdown (another lpar with similar workload but not this appliaction was already down after 7 minutes) D A,L revealed that there were some DB2s plus WBIFN still running plus the necessary system infrastructure. And one thing with the jobname of a TSO user, but OMVSEX in the step info, so the userid belonged to some USS process? thread? application? And they seemend to multiply while I was looking at them. Canceling any of them didn't really help, never mind that the duplicate jobname requires using the asid, which requires a list first. By the time I get around to killing the pid, it's already gone. Then I saw that *something* still had open DB2 threads, for which automation has made provisions and forces things out. So I thought that this must be related to this user. Given that I couldn't stop it from multiplying, much less get out of the system (f bpxoinit,shutdown=forkinit was replied with 'shutdown delayed'), I shut down the fork service. That stopped the multiplication, but a few of those 'user asids with a number' were still around. And it was a VERY bad idea to shutdown the fork service, as that effectively prevented WBIFN from terminating eventually (it never terminates in a timely manner, anyway). I ended up canceling things, which generated tons of coredumps which filled the directory, which eventually prevented the startup of this application. (And no, these useless coredumps cannot be prevented, believe me, I've tried.) The good news was that after 20 minutes I had WBIFN and that userid shut down, and then automation did the rest (in the case of our operators, they never get automation to do 'the rest'). So how are other installations handling system shutdown when there are active USS users (or at least their leftover processes)? For a 'pure' MVS, I can shutdown TSO and the Initiators, cancel any running batch jobs, and I am done. But how do I stop the USS things from multiplying? And this Tuesday, that users leftover processes are back. I tried killing the top one (right under ppid=1), but that only resulted in another process under ppid=1 (that killed process was just dropped). superkill didn't help, either. Isn't there any surefire way to get the whole tree stopped in one fell swoop? (and no, I won't kill pid 1). (An OMVS ignoramus is asking this, so please be gentle with me) 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 _____________________________________________________________________________________________________________________________________ Standard Bank email Disclaimer and confidentiality note This e-mail, its attachments and any rights attaching hereto are, unless the content clearly indicates otherwise, the property of Standard Bank Group Limited and its subsidiaries. It is confidential, private and intended for only the addressee. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail immediately. Do not disclose or use it in any way. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of Standard Bank Group. Standard Bank Group accepts no liability for any loss or damages howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. Standard Bank Group does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS). For information about the Standard Bank Group visit our website http://www.standardbank.com ________________________________________________________________________________________________________________________________________ ---------------------------------------------------------------------- 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
