Lock and unlock jobs
Moderators: chulett, rschirm, roy
Lock and unlock jobs
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
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
-
- Premium Member
- Posts: 142
- Joined: Mon Jun 27, 2005 5:31 pm
- Location: Atlanta GA
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.
Venkat Velagapudi
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.
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.
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.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Premium Member
- Posts: 1255
- Joined: Wed Feb 02, 2005 11:54 am
- Location: United States of America
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 ?
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
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
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
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
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.