![]() |
|
#1
|
|||
|
|||
|
Hi all,
There is an job in my system which is an background job.jobs status is active so that i can not change its status and others. I can not delete it . It do not allow me to cancel it. Can I delete its entry from the database level? Please guide! Regards, Zumba. |
| Sponsors |
|
#2
|
|||
|
|||
|
You can cancel the process which is attached to the job using tx. SM66. cancel without CORE. If that doesn't work, you can try a 'kill -9' on OS-level (or whatever the equivalent in Windows). If that still doesn't work, you are likely to face a zombie. Analyze the cause (but only a coldboot will help you).
Cheers! |
|
#3
|
|||
|
|||
|
Hi Golfi,
Thanks for all the help. What does the kill -9 will do? Will it finish all other jobs as well or just only the specific one? Regards, Zumba. |
|
#4
|
|||
|
|||
|
Hello Zumba,
You had better told us a bit more what exactly your problem is. What is the meaning of: An error message would help here, or even the confirmation that there isn't an error message... Golfi made a guess here, and provided an answer based on the guess. (May be completely correct of course.) I also can imagine a different guess, and the answer based on it: Sometimes there is an inconsistency in SM37; the job might actually not be running any more. In SM37 try this: Job -> check status And about kill -9: It will kill only the processes that you specify on the command line. Provided that your OS is Unix, and you have got the process ids from SM66. Regards, ERP. |
|
#5
|
|||
|
|||
|
ERP is right,
check status is the first thing to try However as I stated many years ago, kill in SM50/SM66/OS level is the last thing. It is a bit like shooting the car not the driver. You are wanting to kill a user running a task in the WP and you kill the WP not the user. Correct killing methodology is rarely taught and in fact works much better, more elegantly and safer. Option A - Waiting CPIC If the process is in a CPIC wait in SM50 then simply cancel the connection it is using in SMGW and it will go away, all other options fail (sometimes even cancelling at the OS) Option B - Other waits If the process is waiting on something else cancelling it will also not kill it and you need to remove the wait situation. For example if doing a large DB update and you kill the process then there may be a large roll back time. Option C - WP Trace file Check the WP trace file, if the last thing logged is an eyecatcher issue, a signal 9/10/11 (depending), a MM dump or something that looks like a memory corruption then you may want to consider stopping the WP from restarting after the error and leaving down until next restart. So change Start after Error in SM50 to no before doing Option D Option D - Going for the kill 1. Try cancelling the job in SM37 2. Try killing the job in SM04 3. Try the "end session" or "Cancel" options in SM50 4. Try cancel without core in SM50 5. Consider killing the PID. Remember with option D you are killing the car, not the driver. You can see the WP restart and the usr jumps back in and starts rerunning. In these cases I set the WP restart to No. and wait 5 minutes after killing. If the user successfully jumps to another WP then cancelling as per option D will work better that the first time now. If after 5 minutes a WP restart brngs the user back in, bring it down until next restart. Memory corruptions in WP are not that rare. Finally, I imagine peopkle will say "it has always worked OK for me". I am just trying to make people appreciate the potential implications of their actions. Regards, Ramma. |
| Entre a los Links relacionados |
![]() |
| Bookmarks |
| Thread Tools | |
| Display Modes | |
|
|