We've had this happen a few times, i am wondering if the product is working as designed.
There are a few reasons why jobs will get stuck in ready state rather than actually executing. The issue we have last week was due to the manager server not being able to communicate to the agent. I've noticed that when a job is stuck in ready, it is considered to be "executing" in regards to the "Overdue if execution time exceeds (in minutes)" field.
In other words, if a job is set to be flagged as overdue if exceeding 10 minutes of execution time, it will be flagged as overdue if it is stuck in ready state for 10 minutes even though it has not actually been executing for 10 minutes. Shouldn't this be changed slightly to prevent false alarms in events like this?
Just for the fun of it I will take the other side of this discussion.
If the job that goes into "READY" state were to sit there for the next week and didn't notify someone would that be OK?
I am expecting this job to finish in 10 minutes. If it doesn't finish in the expected time frame I think someone should get notified. It really doesn't matter why it didn't finish in 10 minutes( aka the server was down).
I think it is working as designed.
Just my 2¢ but open for discussion.
To add to Don's comment. The product is doing exactly what it is supposed to.
READY state means job has been sent to Agent. Normally, as soon as WA Agent gets the job it runs it.
However, if job is stuck in READY and is not changing to to EXEC state, then something may have gone wrong.
There can be two main reasons for this (there can be others as well!):
1. Network issue.
2. Filesystem related issues in the agent (Unix/Linux agents).
Your job may be running or not. The manager/scheduler has no way to know what happened. Hence, the manager side clock will continue to run for the job and if overdue is set then it will (and should) send the overdue alert if the job has not completed.
I agree to Nitin's and Don's comments above.
Thank you everyone for your input on this