Is there a way to turn off the "Run" button in Dir

[CharlesNagy]

We are putting in place an automated Job running system, and as such, we do not want to allow the production monitoring team to run a job on it's own by mistake. We do want them however to be able to monitor job logs so that they know if something is wrong, and can inform us.

Perhaps there is a read only flag somewhere? I have looked and can't find anything.

[sachin1]

yes their is Readonly "0" flag in DSX (.dsx file), which when set to Readonly "1" and imported, will not allow to run a job from datastage designer but will allow to run in director for that particular user/password.

[chulett]

While there is the option to mark something 'Read Only', that is for protecting the design itself - Designer may be used to look at the job but cannot be used to change the job. It has no bearing on it being runnable or not.

I don't believe there is any way to disable the 'Run' option from Director.

[DeepakCorning]

Yeah I also do not think that there is a way but if u want monitoring team to just see the log files you can try some utility which will extract these log files and display them may be on a webpage or something.

I think Disabling run button in the director kind of defies its purpose as a client tool.

[CharlesNagy]

Thanks guys,

Yes, I was hoping for an easy solution, but it looks like I will have to do as suggested, build some kind of display process that will just display the log files.

Thanks all,

Cheers

Yeah I also do not think that there is a way but if u want monitoring team to just see the log files you can try some utility which will extract these log files and display them may be on a webpage or something.

I think Disabling run button in the director kind of defies its purpose as a client tool.

[michaeld]

search for: "Limiting access to only view the job log."

With server jobs, if you don't release them then they will not be runnable for operator users (according to Ray). However, parallel jobs don't have a concept of being released so you're stuck making an interface.

[ray.wurlod]

Create a before-job subroutine that checks whether the job is being run under control. If it is not, set the error flag (ErrorCode argument) to a non-zero value, and log a message indicating that the job can not be run in isolation.

[CharlesNagy]

Thanks, the before job subroutine sounds like the solution, that way Production has full funtionality, but cannot run jobs we don't want them to run.

cheers,

Create a before-job subroutine that checks whether the job is being run under control. If it is not, set the error flag (ErrorCode argument) to a non-zero value, and log a message indicating that the job can not be run in isolation.

[chulett]

Hmmm... not only will you have to add that to every job, but there will be times when you'll want to run a job manually because Something Has Gone Wrong - and this will prevent that.

However, if that works for you... I guess you could create a little wrapper job, a job that runs a single job 'under control' if situations like that come up.

[CharlesNagy]

We have a routine that will update a DSX file automatically with stuff like the addition of a subroutine, but your idea of a 'wrapper job' to run jobs individually is a good one,

Thanks,

Hmmm... not only will you have to add that to every job, but there will be times when you'll want to run a job manually because Something Has Gone Wrong - and this will prevent that.

However, if that works for you... I guess you could create a little wrapper job, a job that runs a single job 'under control' if situations like that come up.