DSXchange

Hi Everyone,

Is there a way to give a developer exclusive rights to an object he/she is developing/customizing (i.e. check-in the object)? At the same time, how would this object's lock be released once the developer is done with it (i.e. check-out the object)?

I know that objects get locked to a certain developer while it is being modified, but what if that user is to leave for the day and would want the object remain locked to his/her username?

Thanks in advance!

Simplest may be to leave it open - but this is not advisable.

Another option is to provide each user a separate project.

Otherwise you can set the permissions in your OS for this purpose.

I think the best answer at this time is no. Setting operating system permissions is not a workable solution IMHO.

It would be possible to use use some kind of source control system outside of DataStage (one that has a check-in, check-out function), but you would still have an unlocked and open job in DataStage.

Others have asked for this, but maybe another voice would help, so how about doing an enhancement request.

Larry

I must disagree with Sainath that you can use OS permissions. In particular, most objects exist as records in database (Repository) tables, rather than as operating system objects. So any approach that uses OS permissions would be an "all or nothing" approach.

DataStage does not have a source code control system. Some sites use external SCCS mechanisms, and the things checked in and out are DataStage export files. This still requires management control over what developers do, and training of them.

wow, this could be an issue.

any suggestions in good practices on how you communicate this to all developers? It would be a challenge for us especially because we have developers across multiple continents. I wouldn't want everyone to have his/her own project. Nor would I want everyone to export their work everyday (which still may lead to some issues).

thanks a lot!!

Depends on your management style. Search the Internet for "Theory X and Theory Y".

Document the rules and procedures, and require compliance. Either explain the reasons to the developers or threaten them with consequences.