DSXchange

Hi,
Considering DataStage does not have a check in check out facilty, how can that be implemented by other means ? I would like to work on a job, and at the end of the day lock it. The next day, I come back and unlock it. Are there any universe commands that would lock a job ? I know I dont have the previlages in administrator to unlock jobs, but I could possibly ask for those previleges. Any ideas on how to do that ?
Thanks.
Ajay

When you say lock it, you mean to say to make it read only or keep it open on your desktop and come back and continue working?

I guess NEO wants to restrict access to the job by others. I mean nobody should be able to modify it. If that is the case yeah you can make the job read only. But its painful for you as well cause it will be read only for you as well. My best bet is to export the job at the EOD in to a .dsx file and import it next morning. I would like to know if there are any better options. I will wait for the gurus to enlighten us.

Read Only sounds good. All I want is for others to know that someone is working on a job before they start modifying it. The responsibility then falls on that person to identify the individual who is working on that job to figure out when they can start using it.

A job locked by a user sounds a better option because that prevents other users from unlocking it, but I think that's harder to implement. The read only option will do the trick just fine in atleast as much as notifying someone that a job is being used. I hope the developers wont make it Not Read Only and start modifying jobs.

I believe jobs can be made read only by updating the DS_JOBS file. I know the experts here would disagree with the idea of meddling with the internals of DataStage, rightly so. But at this point, people modifying each others code is getting out of hand and hard to manage.

Any insight on how best to achieve this ?
Thanks.

What, they just get in and start modifying your jobs ? DS_AUDIT has all the information on what job was accessed and changed by whom. Catch them and get them nuked. This is insane and very unprofessional.

Build another project for yourself, do your development there and ask your adminstrator to only grant your id permission to log onto that project untill you get stuff organized at your environment. This is better and much easier than making your jobs read only everytime you call it a day.

Put a big, brighty-coloured annotation on it

I'm working on this.
DO NOT change it!

ray.wurlod wrote:Put a big, brighty-coloured annotation on it

I'm working on this.
DO NOT change it!

In fairness to the developers, we have been hit by some insane deadlines, and multiple requirements are flowing in often that end up touching the same job. Rather than checking with all the developers if any of them is using a job, which can take time , It becomes a little easy to be able to know that someone is working on it. We tried the simple spread sheet method where developers enter the jobs they are working on, which was not quite successful, as DataStage does not care about the spread sheet. People had a tough time updating the spread sheet too. I feel if something can be done inside datastage that will make a person pause it will be more successful. I was planning to write a routine which they run if they want to hold the job , which takes the jobname as argument and makes it read only. I will also write a routine to do the reverse. This way, things can get a little under control. The onus now falls on the developer to protect his job by invoking the routine. running a routine doesnt sound like a complicated thing to do, and I am guessing the developers wont mind the little overhead. Its just a preliminary thought/idea. What do you think ?

Write the routine as a transform function; it can then be run from its Test grid. But some level of management supervision is still required to prevent misuse.

What would hold a developer from invoking your routine that makes the job writable again? If developers will stop at the sign that this job is being used by someone, then do as Ray suggested, a big annotation that will tell anyone who opens it that this job is still under constructioin and not to change anything.

Sounds like a much simpler plan than trying to lock jobs. I think the red color should work Have to see how it works out

For some reason I like to do things the complex way Heres a thought. Make the developers invoke the routine to make jobs read only. At the same time the routine writes the time and the developer user name to a universe file . Do the same for the reverse process. Now we have a trail of who is working on what and when. I am not sure the same information can be obtained from DS_AUDIT for more than a month into history.
This new table can be queried by me or anyone else to use it as a management tool in assigning work and checking developer productivity. Am I making this too complicated ? and is there a put an annotation in red stupid kind of an answer for this too

Ok, I was reading thru my post again, and my punctuation might have given out the wrong impression. I meant ("put an annotation in red stupid", kind of an answer). Just didnt want anyone who take the time to help folks like me to get offended

DS_AUDIT preserves all history of modification, unless the component is actually deleted and re-created (exported and re-imported).

Unfortunately, there is a lot of exporting and importing done all the time. As requirements change, we import dsx copies from production back into development to be in sync.

Is it possible to lock a job from being changed by locking/changing permissions on any of the internal files of a job, like RT_STATUSxx,RT_CONFIGxx etc. Ideally I wouldnt want any user to make changes and save the job while I hold the lock on the job. Only I should be able to make changes,save, compile and run. Others can use it once I unlock the job.