We are submitting programs via EG 7.1 64-bit on Win10 for execution on a 64-bit AIX server.
We have a proc copy that's copying the data set just fine but the permissions in the target library aren't what we're expecting.
When the program runs, we use umask 002 and so In the source library the data set permissions are 775. But in the target library they're showing as 664. It's not impacting usability but I'd like to know what's going on.
I haven't spoken with a SysAdmin yet but is it possible that the directory permissions are set to default to 664 so that's what they're defaulting to? I thought I'd give the community first crack at telling me what's going on.
Different owner-ids own each directory that the librefs point to, but the same group-id owns both of them.
Our work around is to run the X-command to change the permissions after the copy runs.
Thanks in advance for the help.
John
Oh, wait.
After reading your initial post again, the problem is not with your target, but with your source.
A umask of 002 should always result in a 664 permission on files, and 775 on directories. SAS datasets should not have the executable bit set (what the odd permissions show). So something is not right with the creation of your source datasets.
Do you run the proc copy from the exact same SAS instance that creates the source datasets?
Do the datasets already exist in the target library?
I suspect they're inheriting the folder permissions?
Have you tried the CLONE option on PROC DATASETS?
Wow, this is almost like IM'ing in real time. Thanks to both of you for the fast replies.
Kurt, yes, the same instance of SAS runs the Proc Copy. Actually, it runs soon after the "final" data set is created. We move it because we don't want the users using datasets in our production directories. No, the dataset doesn't exist in the target directory... we rename it as a backup immediately before copying the new one.
Reeza, I didn't look at Proc Datasets. I'm so used to Proc Copy for this sort of thing I didn't consider proc datasets and the options it might have. I'll give it a look and a test run.
John
Oh, wait.
After reading your initial post again, the problem is not with your target, but with your source.
A umask of 002 should always result in a 664 permission on files, and 775 on directories. SAS datasets should not have the executable bit set (what the odd permissions show). So something is not right with the creation of your source datasets.
Wow. It appears I didn't fully understand the one of the basics about Unix permissions.
Forgive me but I just verified your answer and you are correct. umask 002 gives file permissions 664 on files and 775 on directories. I thought everything started with 777!
https://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
Thanks for everyone's help.
SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.