I'm struggling with setting up a 2nd developer on the same project. I have the project permssions set to 775 with dsadm and dstage as the group. I set the umask to 002 and tried changing it to 0002 in the dsenv files in an attempt to fix my problem. The problem happens when user2 runs a job that have hash files with delete and create option. This causes the job to abort because of the permssion on the Hash file directory in the project changes to 755 with dsadm as the owner. I also had to give user2 dba privilage to get him to run these jobs. What is the best way to do this???
error msg in director:
GetLQTablesBatch19902..HashXref2.ToHashXref2: DSD.UVOpen "HashXref2" is already in your VOC file as a file definition record.
File name =
File not created.
Any help is highly appreciated.
Notice: We have upgraded developerWorks Community to the latest version of IBM Connections. For more information, read our upgrade FAQ.
Re: User permission on Unix2004-06-17T20:22:37ZThis is the accepted answer. This is the accepted answer.Nazek
Jobs run as phantoms or background processes. The umask is not read from your .profile or /etc/profile. It has to be set in the kernel or in dsenv. You cannot set umask to 0002 but you can set permissions on the project directory to 4770.
chmod -R 4770 ProjectDir
This should allow anyone in the group to delete the files created by another user in the dstage group.
chgrp -R dstage ProjectDir
This should fix your problem. After you change dsenv then you need to stop and start DataStage.
Re: User permission on Unix2004-06-18T08:38:55ZThis is the accepted answer. This is the accepted answer.Kim,
I tried changing the permssion on the project to 4770 like you mentioned, but it still changed the permssions on the Hash file directory to 700 after running the job as dsadm/owner. I also set the umask in dsenv to 3007 to match the chmod 4770 and stoped and start DataStage before running the job.
Anything else that I should try?
Re: User permission on Unix2004-06-18T10:38:11ZThis is the accepted answer. This is the accepted answer.umask only takes 3 numbers. I am sure it is not working. You could write a job to check. In the control code:
cmd = "SH -c umask"
DSLogInfo(cmd, "Job control")
execute cmd capturing output
DSLogInfo(output, "Job control")
Compile and run this job. You may need to put the full path on umask like /bin/umask.
The way umask with UNIX works is it only puts execute permission on directories created. Anyway
Is what you want. The default in your UNIX is probably 022.
Re: User permission on Unix2004-06-18T12:23:52ZThis is the accepted answer. This is the accepted answer.I had to set umask in both the ds.rc and the dsenv files to avoid a bug with recurring scheduled jobs on v6.0.1. I don't know if v7 has the same issues or not (HP-UX, server job)
Re: User permission on Unix2004-06-18T18:10:05ZThis is the accepted answer. This is the accepted answer.You should not have to do that. The dsenv file should effect all DataStage jobs even ones in the scheduler. If not then I have never seen or heard of this problem. Maybe Ray has.
Re: User permission on Unix2004-06-19T19:53:39ZThis is the accepted answer. This is the accepted answer.Haven't seen it, but I work with very few HP-UX servers. It's these that also had the initial Mutex lock issues, and it's also these that blew almost everyone out of the water by changing the location of the system libraries in HP-UX 11.
I've never had a problem with umask that needed a umask setting in ds.rc (or even uv.rc). Setting it in dsenv has been sufficient. Then again, I've not had any client using cron for recurring scheduled jobs; my "best practice" is to implement this with DataStage job control that is scheduled to run once per day.
Re: User permission on Unix2004-06-19T21:44:27ZThis is the accepted answer. This is the accepted answer.I had to set umask in both the ds.rc and the dsenv files to avoid a bug with recurring scheduled jobs on v6.0.1. I don't know if v7 has the same issues or not (HP-UX, server job)[/quote:37bbbc8e71]
Tony - what bug exactly? We use Control-M for the vast majority of our scheduling, but some still runs thru cron and it is invariably of the recurring type. I've seen no bugs from it, or at least none I've noticed. HP/UX, both 6.x and 7.x server jobs, hence the question.
Re: User permission on Unix2004-06-21T09:35:04ZThis is the accepted answer. This is the accepted answer.The version 6 installation instructions indicates that umask should only be set in the ds.rc file and not in dsenv. My experience with a recent Datastage install confirms that umask in dsenv does not work for all case. I would recommend you check the iniittab for the location of the ds.rc file that is being used. I'm also assuming that you've restarted the server daemon so your changes will take affect.
Re: User permission on Unix2004-06-21T11:45:33ZThis is the accepted answer. This is the accepted answer.Thank you all for your comments.
Actually the dsenv umask does not work. Support said this changed since version 6, they moved it to ds.rc file and I had to stop and start UV to apply the changes. This worked! I haven't tested the scheduler yet, I will try it to make sure it works too after moving the umask to ds.rc file ( I'm working on 7.1 upgrade having 6.1 in production). I think they need to add this information to the Unix documentation of how to set up new groups/users to projects.
Re: User permission on Unix2004-06-28T11:43:38ZThis is the accepted answer. This is the accepted answer.quote:61da5a8098Tony - what bug exactly? We use Control-M for the vast majority of our scheduling, but some still runs thru cron and it is invariably of the recurring type. I've seen no bugs from it, or at least none I've noticed. HP/UX, both 6.x and 7.x server jobs, hence the question.
We had a problem with permissions of hash files and other files created by DataStage jobs. But only if the job was scheduled as a recurring job through the scheduler (i.e. cron). If the job was run manually, or scheduled as a one time job in the scheduler(i.e. at command), it would work correctly. The support engineer that I was working with was able to duplicate this on their systems. This occurred on v6.0.1. I haven't tried it on v7.1.0 yet. When we did a umask command it reported '02' when we ran the job manually or as a one time job in the scheduler. It reported '022' when we ran the job as a recurring job in the scheduler. We had the umask command in the ds.rc file and had to add it to the dsenv file to resolve this issue.
You may not have seen this, if you already had the umask in the dsenv, as it was before v6 (as others have already stated).
Re: User permission on Unix2004-06-28T21:50:00ZThis is the accepted answer. This is the accepted answer.Hey Tony - thanks for the clarification! For all I know we've got the same issue (don't think so) but we run all of our jobs under a single userid to hopefully avoid issues like this.
Take it easy,
Re: User permission on Unix2004-06-29T09:05:03ZThis is the accepted answer. This is the accepted answer.quote:318d86a2cb...but we run all of our jobs under a single userid to hopefully avoid issues like this...[/quote:318d86a2cb]
Yeah, we normally do too, Craig. We ran into issues when we had a job fail and the developer was trying to troubleshoot or re-run the job.
You could tell that the support engineer thought I was looney when I told her how to duplicate it. My reputation was redeemed once she duplicated it on their hardware. :)