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

I have several pieces of code similar to this:

 

data rtlrsk_homeeq_frl_201505;
set user.rtlrsk_homeeq_frl_201505;
loan_id=put(input(account_id,best17.),z20.);
run;

 

For ease I was using the same name from the permanent library and my work library.  These pieces of code have written to the permanent library.  The problem is I looked at several like this:

 

data rtlrsk_homeeq_frl_201505;
set user.rtlrsk_homeeq_frl_201505(obs=10);
run;

 

So now the permanent librarys have been trashed.  Is this common, a know issue or something that anyone has seen before? 

 

Thanks in advance,

 

Mark

 

1 ACCEPTED SOLUTION

Accepted Solutions
Astounding
PROC Star

There is a global option, USER=, which controls where single-level SAS data set names get stored.  The default value for this option is USER=WORK, which is why single-level data set names get stored in the WORK library.  One use of this option is to automatically save single-level data set names.  If you were to code the option as USER=MYLIB, single-level data set names would be scored within MYLIB.

 

Evidently, USER as a LIBNAME is another way of overriding where single-level SAS data set names get stored.  Avoid USER, avoid WORK as libnames, and this problem should vanish.  You can probably confirm this by looking within USER, and noticing many additional SAS data set names that you didn't expect to find there.  Probably every single-level SAS data set name mentioned within your program will magically appear in that library.

View solution in original post

8 REPLIES 8
RW9
Diamond | Level 26 RW9
Diamond | Level 26

Are you saying that your work library points to the same physical location as the user library?

%put %sysfunc(pathname(work));
%put %sysfunc(pathname(user));

If so that sounds like either: a) your setup program have re-assigned work location, b) or somewhere in the code that has happened. Not sure why that would be the case.  Not that it helps much now, but I would always put access rights on libname statements:

libname user "..." access=read;

To avoid this accidental overwriting.

Steelers_In_DC
Barite | Level 11

The log shows this:

22         GOPTIONS ACCESSIBLE;
23         %put %sysfunc(pathname(work));
/sas/saswork/SAS_workBFD300003535_scsmt300a/SAS_work3ED700003535_scsmt300a
24         %put %sysfunc(pathname(user));
 

There is no path for user.  But I have another library (mortgage) with the same issue that shows the correct path. 

 

I just tried to duplicate the problem in a single code to paste the log and it did not happen again.  Thank you for the access=read option, that is new to me.  I will use that going forward.  I'm 99% sure it was not user error but am not sure what the issue is since I cannot duplicate.

Reeza
Super User
The obs option restricts what's brought in to the data step, which is writing to the work library. Your work library contains a subset of the data in your user library, but your user library should be fine.
Steelers_In_DC
Barite | Level 11

I understand that but it did make a change to the library.  Another insane issue is that I do not have write access to these librarys, but from my perspective there are large changes, adding columns, limiting dataset to 10 rows.

Steelers_In_DC
Barite | Level 11

I'm looking at my ftp site to see what is in that library.  Here's another piece of code I used:

 

data match_user nomatch_user match_usereq nomatch_usereq match_frl nomatch_frl;
merge Consolidated_Loan_Sale_Data(in=a)
      rtlrsk_mortgage_201506(in=b)
      rtlrsk_homeeq_201506(in=c)
      rtlrsk_homeeq_frl_201505(in=d);
by loan_id;
if a and b then output match_user;
if a and not b then output nomatch_user;
if a and c then output match_usereq;
if a and not c then output nomatch_usereq;
if a and d then output match_frl;
if a and not d then output nomatch_frl;
run;

 

All of the outputs that should be in my work library are in the 'user' library.

ballardw
Super User

If you use a SAS USER library and not just a library called USER then one level names default to the USER library, not WORK. If you want to put things into work then you must explicitly use work.dataset notation.

 

Yet another reason to be extremely cautious with using the construct.

 

data dataname;

    set dataname;

 

Just because you can doesn't mean it is a good idea. Be very conscience of choosing that choice when using it.

Astounding
PROC Star

There is a global option, USER=, which controls where single-level SAS data set names get stored.  The default value for this option is USER=WORK, which is why single-level data set names get stored in the WORK library.  One use of this option is to automatically save single-level data set names.  If you were to code the option as USER=MYLIB, single-level data set names would be scored within MYLIB.

 

Evidently, USER as a LIBNAME is another way of overriding where single-level SAS data set names get stored.  Avoid USER, avoid WORK as libnames, and this problem should vanish.  You can probably confirm this by looking within USER, and noticing many additional SAS data set names that you didn't expect to find there.  Probably every single-level SAS data set name mentioned within your program will magically appear in that library.

Steelers_In_DC
Barite | Level 11

That makes sense.  Learned a lot in this thread.  Thank you everyone.

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

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.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 8 replies
  • 1069 views
  • 2 likes
  • 5 in conversation