DSXchange

When I try to schedule a job in Director, an atjob is created in UNIX and the job will run, however it does not show up in the scheduler window. Does anyone know why this might be happening? Thanks!

Hmm... the classic answer would be because you are not checking using the same userid that did the scheduling. But if it's always you, then something else must be going on.

I've seen that behaviour once or twice running in a clustered environment, but I can't say for sure the clustering had anything to do with it. There were the obvious times when the crontab entries were on another node but then there were other times where they were in the right place but still not showing up. Stopping and restarting the DataStage server fixed the problem for me, from what I recall. Never did find out why it happened.

Do you know of Director needs any special permission on the atjobs directory? Another bit of information, this just started happening after they upgraded our AIX operating system. I'll try re-starting the environment tomorrow morning regardless and seeing if that solves the problem. Thanks!

j.anderson@thomson.com wrote:Do you know of Director needs any special permission on the atjobs directory?

Don't think so. You need to have been granted permission to submit 'at' jobs, much like for cron with its 'cron allow' concept. If you didn't have the permissions you needed, you wouldn't be able to schedule the job, let alone have it run under the control of the scheduler. The whole "right after our AIX upgrade" thing is more than a coincidence, I would say.

What happens when you do something other than a 'one off' job schedule? Do 'cron' entries show up fine for you in the Scheduler window, just not 'at' entries?

Yeah, if I do an "every Thursday @ 7:00am" schedule, it shows up in the crontab just fine and is viewable in Director. It's when I have a "thursday the 21st @ 7:00am" job that it creates the atjob fine, but it is not viewable in Director.

This is quite a head scratcher

This is one where server side tracing may aid diagnosis. Enable server side tracing (from Administrator or DS.TOOLS menu) then open Director. Switch to Schedule view. Then close Director and disable server side tracing. Inspect the trace file (DSR_TRACE...) to see how the server was being queried. Chances are it's through a helper subroutine, so you may then need to involve your support provider to find out which of the helper subroutines might be implicated. Otherwise you may be able to figure out from the arguments what's going on.

What are your UNIX permissions for /usr/spool/cron/atjobs? Your id will need r-x in order for Director to see them I believe.

-Howie

Hi,
the reason for what you have is the difference between they AT and crontab in unix.
I have a similar (reversed situation) if I schedual only 1 run (naturally using the system at command) it never runs.
basically you need your sysadmins to give you permissions and fix it so the user you use in the Director has permitions for it.

the odd thing about this (in my case) is that DS never gives any failiour notification that it failed to set the at command.

IHTH,

That's why you need r-x for /usr/spool/cron/atjobs - to view/execute the jobs scheduled once. You also need r-x for /usr/spool/cron/crontabs, to view/execute the jobs scheduled persistently.

hgalusha wrote:That's why you need r-x for /usr/spool/cron/atjobs - to view/execute the jobs scheduled once. You also need r-x for /usr/spool/cron/crontabs, to view/execute the jobs scheduled persistently.

I just fonud this thread because I am having this problem. THe Unix support dept will not grant this permission, because it would allow us to see other users' scheduled jobs.