DSXchange

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?

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,

Scheduling through director. When checking the crontab list (crontab -l) there is nothing there for this user.

No hung processes, I shutdown/restarted DS to make sure.

I cannot access "Scheduling" tab through Administrator using the administrator login or the dsadmin login.

Triton46 wrote:I cannot access "Scheduling" tab through Administrator using the administrator login or the dsadmin login.

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.

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 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?

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.

Not sure what I did, but now I can see entries in "crontab -l" for scheduled jobs. Jobs still are not running though.

found it!

user does not have access to run cron. Anyone know where "at" is located?

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.

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.

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.

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.

Thanks for the advice Craig.

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:

Error calling subroutine: DSR_SCHEDULE(Action=1); check DataStage is set up correctly in project DRDWProj (Subroutine failed to complete successfully (30107))

I don't get this error in the other project, the job schedules but will not run.

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