BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
bentleyj1
Quartz | Level 8

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

1 ACCEPTED SOLUTION

Accepted Solutions
Kurt_Bremser
Super User

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.

View solution in original post

5 REPLIES 5
Kurt_Bremser
Super User

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?

Reeza
Super User

I suspect they're inheriting the folder permissions?

 

Have you tried the CLONE option on PROC DATASETS?

bentleyj1
Quartz | Level 8

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

Kurt_Bremser
Super User

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.

bentleyj1
Quartz | Level 8

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: Save the Date

 SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!

Save the date!

How to Concatenate Values

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.

SAS Training: Just a Click Away

 Ready to level-up your skills? Choose your own adventure.

Browse our catalog!

Discussion stats
  • 5 replies
  • 1309 views
  • 2 likes
  • 3 in conversation