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.
This topic has been locked.
13 replies Latest Post - 2004-06-29T09:05:03Z by SystemAdmin
Pinned topic User permission on Unix
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2004-06-29T09:05:03Z at 2004-06-29T09:05:03Z by SystemAdmin
Re: User permission on Unix2004-06-17T20:22:37Z in response to SystemAdminNazek
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:55Z in response to SystemAdminKim,
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:11Z in response to SystemAdminumask 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-19T19:53:39Z in response to SystemAdminHaven'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:27Z in response to SystemAdminI 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:04Z in response to SystemAdminThe 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:33Z in response to SystemAdminThank 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:38Z in response to SystemAdminquote: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:00Z in response to SystemAdminHey 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:03Z in response to SystemAdminquote: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. :)