Protected Projects and DataStage Operator role

[latadrawal]

Hi,

With Protected projects, we found out that the users belonging to the role of a DataStage Operator only have access to the Director. In addition to that, the Operator can only execute,reset jobs and view logs in the Director if the jobs are "released". Why is that so ?

Also, if we Release a job, it appends the release number to the job name. Shouldn't the release information be incorporated in the job's properties rather than in its name ?

Thanks.

[chulett]

With Protected projects, we found out that the users belonging to the role of a DataStage Operator only have access to the Director. In addition to that, the Operator can only execute,reset jobs and view logs in the Director if the jobs are "released". Why is that so ?

No clue. I think that all we can say as users is that it's just how they decided to implement it. This is puzzling to me, as the process of 'releasing' jobs is pretty much obsolete with the advent of Version Control. IMHO.

Also, if we Release a job, it appends the release number to the job name. Shouldn't the release information be incorporated in the job's properties rather than in its name ?

Again, that's the way it works. It's really not something you have to worry about as you still refer to the job via its unreleased name. You can have multiple released versions of a job in a Project and when you run job 'xxxx', it will run the highest released version of the job that it can find. You should never have to worry about running 'xxxx%rel_22' one release and then having to change everything to reflect 'xxxx%rel_23' after the next release.

[latadrawal]

Thanks for the quick response.
We are not using the Version Control tool. We use the .dsx for migrating code. Importing the .dsx into a Protected project does not allow for the Operator to be able to view the jobs in the Director, unless the jobs are released. Also, jobs cannot be released in a Protected project, the project needs to be un-protected first , the job needs to be released and then the Projects needs to be made protected. Quite a tedious process !!!
However, using the Protected project with the .dsx approach for code migration is the only way we can get the code to be in a read-only state.

And about the release information appended to the job name, we use the dsjob command from within a shellscript to trigger the DataStage job.
With the dsjob command one has to specify the exact job name as it is. So with released jobs, we have to provide the jobname+release number.
We are using the dsjob command in a shellscript and an external scheduler then triggers this shellscript which in turn triggers the DataStage job.

In short what I am looking for is a way to have users with the Operator role to be able to view jobs in a Protected project without the jobs having to be released or promoted using the Version Control tool.

Thanks.

With Protected projects, we found out that the users belonging to the role of a DataStage Operator only have access to the Director. In addition to that, the Operator can only execute,reset jobs and view logs in the Director if the jobs are "released". Why is that so ?

No clue. I think that all we can say as users is that it's just how they decided to implement it. This is puzzling to me, as the process of 'releasing' jobs is pretty much obsolete with the advent of Version Control. IMHO.

Also, if we Release a job, it appends the release number to the job name. Shouldn't the release information be incorporated in the job's properties rather than in its name ?

Again, that's the way it works. It's really not something you have to worry about as you still refer to the job via its unreleased name. You can have multiple released versions of a job in a Project and when you run job 'xxxx', it will run the highest released version of the job that it can find. You should never have to worry about running 'xxxx%rel_22' one release and then having to change everything to reflect 'xxxx%rel_23' after the next release.

[tonystark622]

If a job truly is "released" you should not have to specify the job name plus the release number. At least the last time I tried it.

Tony

[chulett]

However, using the Protected project with the .dsx approach for code migration is the only way we can get the code to be in a read-only state.

Version Control will do this for you automatically without having to use a protected project.

And about the release information appended to the job name, we use the dsjob command from within a shellscript to trigger the DataStage job. With the dsjob command one has to specify the exact job name as it is. So with released jobs, we have to provide the jobname+release number. We are using the dsjob command in a shellscript and an external scheduler then triggers this shellscript which in turn triggers the DataStage job.

As I (and Tony) have said, this isn't true. Or at least it wasn't the last time I used Released jobs. Granted, that was awhile ago, but I sincerely doubt they have made a fundamental change like that, especially one that makes no sense. I think you'll find that while you can specify the full released jobname, you aren't required to.

In short what I am looking for is a way to have users with the Operator role to be able to view jobs in a Protected project without the jobs having to be released or promoted using the Version Control tool.

Stop looking - it can't be done. Use Version Control.