Ismet -- You should be able to send a mupip interrupt to the hung process and get it to dump its current state.
If it is in a tight loop, it should be burning CPU cycles, and should show up under "top" By "corruption" I think Greg means inconsistent data from an application perspective. If there is reason to suspect database structural integrity, a mupip integ can be used to test for structural integrity. Also, is an M lock deadlock ruled out? lke with a show -all -wait will tell you about locks owned by processes and processes waiting for those locks. Regards -- Bhaskar Greg Woodhouse wrote: > If you can replicate the problem, I'd recommed signing in through ^ZU > and interrupting the process with kill -2. I don't know if ctrl-C will > even send an interrupt, it might just break the connection. > > Look at the option definition and see if there is any code vulnerable > tyo being put into a tight loop if certain variables are dedfined in > your environment. Finally, and this is a long shot, it's just possible > that a corruption of some sort in ^XUTL has caused a node to point back > to itself. (Note, BTW, that data in ^XUTL is stored under the user's > DUZ. Did you sign in as the same user each time?) Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
