We are running DS 5.2 on 8 servers. One of the development servers will not acknowledge a scheduled job. We had the same issue on another server, but after running the job once or shutting down the server (one of them fixed it) the job now runs.
Our other server, however, is not responding. What do I need to check for scheduling jobs?
Scheduled Job Never Runs!!!
Moderators: chulett, rschirm, roy
Re: Scheduled Job Never Runs!!!
Are you using Director or Crontab for scheduling ?
Hi,
did you check for hung process of that job? this makes the job in a none runable state and can't be prepared as well.
IHTH,
did you check for hung process of that job? this makes the job in a none runable state and can't be prepared as well.
IHTH,
Roy R.
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
That tab is for NT servers only.Triton46 wrote:I cannot access "Scheduling" tab through Administrator using the administrator login or the dsadmin login.
Scheduling thru the Director to a UNIX server builds 'cron' or 'at' commands. Are you sure that your user that you are connecting as has been granted access to cron/at? They need to be added to 'cron allow' for instance, but you should be getting errors - not schedules that vanish - if they aren't.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
The other servers do not use cron.allow, we have a few entries in cron.deny but none of them are the user I am using. Do I need to chmod the cron and at files?chulett wrote: That tab is for NT servers only.
Scheduling thru the Director to a UNIX server builds 'cron' or 'at' commands. Are you sure that your user that you are connecting as has been granted access to cron/at? They need to be added to 'cron allow' for instance, but you should be getting errors - not schedules that vanish - if they aren't.
The schedule doesn't vanish. It shows it as scheduled at say 4:55pm..4:55pm comes and goes and the job never runs. No log entries.
Well....ignore that...turns out we do have access to cron...so now I am unsure why cron won't pick up the DS job.
I found another post on here about this where the last post says to chmod the &COMO& file to 777. That seems to have allowed me to see jobs when I do a crontab -l...I guess...but it still won't pick them up.
I found another post on here about this where the last post says to chmod the &COMO& file to 777. That seems to have allowed me to see jobs when I do a crontab -l...I guess...but it still won't pick them up.
One last shot here...
Do you have this issue with one job or with any jobs? Are you sure that absolutely nothing gets logged? I have seen situations where cron would try to start a job and for whatever reason, couldn't. All I saw in the log was the single DSR.SCHED record that indicated the start of a 'scheduled' job via cron, but nothing else. The odder thing was that the Status view would still show the last run time, not the time of the attempted cron start. For me though, this was highly sporadic. The job would run fine for days at a time and then suddenly one day not run. The next day it would go back to running fine. Support was never able to really nail down what was going on.
Speaking of which, have you opened a case with Support on this? I'd suggest that as a next step.
Do you have this issue with one job or with any jobs? Are you sure that absolutely nothing gets logged? I have seen situations where cron would try to start a job and for whatever reason, couldn't. All I saw in the log was the single DSR.SCHED record that indicated the start of a 'scheduled' job via cron, but nothing else. The odder thing was that the Status view would still show the last run time, not the time of the attempted cron start. For me though, this was highly sporadic. The job would run fine for days at a time and then suddenly one day not run. The next day it would go back to running fine. Support was never able to really nail down what was going on.
Speaking of which, have you opened a case with Support on this? I'd suggest that as a next step.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
The user you used to create the crontab needs to be in the same group as the DataStage developers. &COMO& has nothing to do with a job not running but there plenty of other files which do. I would not chmod 777 on the whole project directory just to solve this problem. You need to add the user that created the crontab to the same group that owns all the jobs.
Mamu Kim
Thanks for the advice Craig.chulett wrote:One last shot here...
Do you have this issue with one job or with any jobs? Are you sure that absolutely nothing gets logged? I have seen situations where cron would try to start a job and for whatever reason, couldn't. All I saw in the log was the single DSR.SCHED record that indicated the start of a 'scheduled' job via cron, but nothing else. The odder thing was that the Status view would still show the last run time, not the time of the attempted cron start. For me though, this was highly sporadic. The job would run fine for days at a time and then suddenly one day not run. The next day it would go back to running fine. Support was never able to really nail down what was going on.
Speaking of which, have you opened a case with Support on this? I'd suggest that as a next step.
This happens with any job... no log entry or status change. We've had the sporatic "job didn't run last night" problem as well. I have opened a ticket with DS. They are checking through old solutions to see what fits.
I tried to schedule a job in another project on that folder and I get the following error:
I don't get this error in the other project, the job schedules but will not run.Error calling subroutine: DSR_SCHEDULE(Action=1); check DataStage is set up correctly in project DRDWProj (Subroutine failed to complete successfully (30107))
If jobs sometimes don't startup, it may be time to make the T30FILES parameter larger (search for it on this site).
We've had it in the past where this maximum number of concurrent open hash files was reached and this results in some jobs not starting (since each job needs 4 hashfiles just to start).
Ogmios
We've had it in the past where this maximum number of concurrent open hash files was reached and this results in some jobs not starting (since each job needs 4 hashfiles just to start).
Ogmios