SAP-Forum.ORG
   
This web site isn't affiliated with, sponsored by, or approved by SAP AG. Is only a SAP users community.

Go Back   SAP-Forum.ORG > SAP Forums > SAP BASIS

Aprenda SAP!
Reply
 
Thread Tools Display Modes
  #1  
Old 06-22-2010, 01:27 PM
Zumba Zumba is offline
Senior Member
 
Join Date: May 2010
Location: Colorado
Posts: 240
Default Backgroung jobs

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.
Reply With Quote
Sponsors
  #2  
Old 06-22-2010, 01:29 PM
Golfi Golfi is offline
Senior Member
 
Join Date: May 2010
Location: Delaware
Posts: 824
Default Re: backgroung jobs

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!
Reply With Quote
  #3  
Old 06-22-2010, 01:32 PM
Zumba Zumba is offline
Senior Member
 
Join Date: May 2010
Location: Colorado
Posts: 240
Default Re: backgroung jobs

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.
Reply With Quote
  #4  
Old 06-22-2010, 01:37 PM
ERP ERP is offline
Senior Member
 
Join Date: May 2010
Location: Rhode Island
Posts: 231
Default Re: backgroung jobs

Hello Zumba,

You had better told us a bit more what exactly your problem is.
What is the meaning of:
Quote:
Originally Posted by Zumba View Post
It do not allow me to cancel it.
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.
Reply With Quote
  #5  
Old 06-22-2010, 01:40 PM
Ramma Ramma is offline
Senior Member
 
Join Date: May 2010
Location: California
Posts: 287
Default Re: backgroung jobs

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.
Reply With Quote
Entre a los Links relacionados
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 10:28 AM.


Powered by vBulletin® Version 3.7.4
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Forum Design By inferno