DSXchange

How can you protect a job from being deleted. I know how to make them readonly, but not how to protect them from being deleted. Could something be done in the administrator command window? One solution I can think of is to somehow lock the jobs. As if someone is working on them. That way DataStage wouldnt let you delete the jobs. Is it possible to lock jobs like that?
Thanks folks.
Jay

Would'nt making the jobs read only protect them frm deletion?

Nope!!

You need to make the project a 'Protected' project. And yes, via the Administrator.

chulett wrote:You need to make the project a 'Protected' project. And yes, via the Administrator.

I would like to do that only for a few specific important jobs in the project though.

Can't be done as far as I know. Protect the project.

hello Craig,

Can a project be brought back to un-protected state from being a protected project?

I mean, once we make a project protected. Can we undo that operation?

Thanks much,
Naveen.

Sure. It's basically a 'switch' managed from the Administrator client.

chulett wrote:Sure. It's basically a 'switch' managed from the Administrator client.

I was able to lock jobs from delete by changing the permissions on the internal files of the jobs. I tried this on some test jobs. Seems to work. As long as I use chmod -R 544 on the *220(220 my job num,which will include RT_LOG220,RT_BP220,RT_CONFIG220 etc) they cant be deleted by me either. My goal is to keep a few important jobs under my control, where anyone who needs to make changes to these jobs are forced to come to me, so that they are released. People have been making copies at random, making changes to the code, deleting the original and reverting the copies back to original. When more than one person is working on the same job, they end up reverting each other's code. Its kind of getting out of control who ends up changing what in an existing job.

My question here is,
is there any harm in following this approach of locking jobs. I dont want to end up with a bigger problem solving a smaller problem

Thanks.
jay

I think ascential gives only project level security.
It'll be good if they extend this security level to
Project ---->category ----> Jobs or low level components.

NEO wrote:

chulett wrote:Sure. It's basically a 'switch' managed from the Administrator client.

I was able to lock jobs from delete by changing the permissions on the internal files of the jobs. I tried this on some test jobs. Seems to work. As long as I use chmod -R 544 on the *220(220 my job num,which will include RT_LOG220,RT_BP220,RT_CONFIG220 etc) they cant be deleted by me either. My goal is to keep a few important jobs under my control, where anyone who needs to make changes to these jobs are forced to come to me, so that they are released. People have been making copies at random, making changes to the code, deleting the original and reverting the copies back to original. When more than one person is working on the same job, they end up reverting each other's code. Its kind of getting out of control who ends up changing what in an existing job.

My question here is,
is there any harm in following this approach of locking jobs. I dont want to end up with a bigger problem solving a smaller problem

Thanks.
jay

Your approach does not offer any protection against the design-time objects from being deleted. These have no visibility at the operating system level, being primarily rows in the tables DS_JOBS and DS_JOBOBJECTS (plus DS_ROUTINES, DS_TRANSFORMS and so on).

If, as you say, protecting the run-time tables prevents deletion via the clients, then you're relying on sensible coding from the engineers, an admirable vote of confidence in them but not a viable strategy for a true paranoiac. And, remember, paranoia is a prerequisite for being an effective DBA.

Your approach does not offer any protection against the design-time objects from being deleted. These have no visibility at the operating system level, being primarily rows in the tables DS_JOBS and DS_JOBOBJECTS (plus DS_ROUTINES, DS_TRANSFORMS and so on).

If, as you say, protecting the run-time tables prevents deletion via the clients, then you're relying on sensible coding from the engineers, an admirable vote of confidence in them but not a viable strategy for a true paranoiac. And, remember, paranoia is a prerequisite for being an effective DBA.

On second thoughts, I have decided that I just want to protect some jobs in a project from delete. I would like these jobs to be able to be modified by anyone, compiled and run, but just not delete them. The issue arises from the fact that multiple people delete originals and rename copies, and thats the main problem. Apparently making the job ReadOnly doesnt save it from deletions.
I guess if I change the permissions on some internal files to only read access to others and permissions on all other jobnum files (RT_LOGxxx,RT_CONFIGxxx etc) to read write execute access to others,they might be able to compile run and make changes to code but just not be able to delete the job.
Any thoughts on what files should have what permissions to accomplish this. I will run some tests myself in the mean time.
thanks.