Page 1 of 2

Posted: Tue Aug 11, 2009 8:34 pm
by vmcburney
I'm not sure how you prevent someone from running jobs. You might be able to supply access through the Information Server Reporting console and maybe Metadata Workbench. If you can navigate the difficult reporting interface you can set up some reports showing error, warning and log messages across jobs plus you can save HTML job reports that show a picture of the job and the properties of each stage in the job. These get saved into the reporting area. If find it all tricky to use and navigate but you might be able to make something of it.

Posted: Tue Aug 11, 2009 10:50 pm
by kduke
It can be done. It does not work well in version 7. Not sure about 8. You need write permission to the RT_* files to run a job. Take away write permission for whatever group they are in.

Posted: Tue Aug 11, 2009 11:04 pm
by chulett
So... to clarify... while you can't stop people from trying to run jobs, you can ensure that the jobs won't run properly if they do? What does actually happen in that case, I'm assuming the job aborts before it gets very far, yes?

Posted: Wed Aug 12, 2009 9:55 am
by kduke
That is correct. The job aborts. If they try to add a new job or save as on an old job then it leaves the next job number locked. Now nobody can add a job untill this lock is released. Lots of little problems. Same for routines.

Posted: Wed Aug 12, 2009 12:10 pm
by sjfearnside
You may be able to accomplish that by ensuring they are:
- in a restricted role, say operator for the project and
- assigned to the unix group of others that only has read access.

Posted: Wed Aug 12, 2009 3:17 pm
by narayana_382
I doubt whether we can restrict any user just to view the director logs and not allowing them to run any job.
Operator user only can reset and run the jobs, but cannot make job changes or compile the objects through the designer.
I dont know if there is a rule or group that is less complicated to that was explained above available in 8.1

Posted: Mon Aug 17, 2009 1:34 pm
by mandyli
Thanks for your help.

Let try with sjfearnside option.


Thanks
Man

Posted: Wed Aug 19, 2009 8:10 pm
by mandyli
Hi

I have tried different option like sjfearnside option also.

But still I can able to run the job from Datastage director.

Is any other option is there.


Thanks Man

Posted: Wed Aug 19, 2009 8:18 pm
by chulett
Why, there would still be the kduke option. Similar in taste to the sjfearnside option, but with a tangy twist of lemon.

Posted: Thu Aug 20, 2009 10:33 am
by mandyli
Hi chulett

Thanks for your reply. I am not able to follow up kduke reply.


kduke : Can you please help me to understand ?


Thanks
Man

Posted: Thu Aug 20, 2009 12:08 pm
by kduke
The problems with doing it at the UNIX level is that DataStage does not know it is restricted at the UNIX level so it tries to update a job when it is not possible at the UNIX level. This leaves records locked like the next job number. So project becomes frozen to the real developers. So as long as a restriced user never tries to create a job then you are fine.

Similar things happen when you try to run jobs and your user cannot write to the RT_* files. These processes become blocked at the UNIX level. Some admin has to delete these blocked or frozen processes.

It keeps users from doing things that you do not want them to do but it does not work smoothly. Version 8 created more roles to try to resolve this issue. If you work within the limits of the tool then it runs smoothly. You can trick it into doing something it was not designed to do but there is always a price to pay.

Someone owes me a twist of lemon.

Posted: Thu Aug 20, 2009 1:01 pm
by chulett
On the way, my friend, on the way. :wink:

Posted: Thu Aug 20, 2009 2:01 pm
by sjfearnside
I just did a test and when the UID was in the role of DS/QS operator and had read only unix rights on either the &PH& folder or the DS_JOB folder and I was not able to execute the job from the client or director. When I added the execute priviledge to the folder it was able to execute the job.

These were the folder under the project. In all cases I was able to abort the job regardless of the rights at the unix level. However, with read only rights to the folder I was not able to reset the job.

My environment may be setup different than yours so I can't guarantee it will work for you but try it if you have a test environment.

P.S. There may be some good reasons you would not want to do that but if a UID is setup for non executable person, just ensure they are not in anything but the "other" group priviledge with read only access.

Posted: Thu Aug 20, 2009 2:32 pm
by mandyli
Yes

I am on the way.


Thanks for your inputs. I will try it once again for as per sjfearnside suggestion.


Thanks
Man

Posted: Thu Aug 20, 2009 2:34 pm
by mandyli
Hi

Here I have one more question.

How will I make &PH& folder or DS_JOB folder read only for one user(UID).



Thanks
Man