DATA Step, Macro, Functions and more

work library question

Accepted Solution Solved
Reply
Valued Guide
Posts: 860
Accepted Solution

work library question

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

 


Accepted Solutions
Solution
‎01-07-2016 10:58 AM
Super User
Posts: 5,516

Re: work library question

Posted in reply to Steelers_In_DC

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


All Replies
Super User
Super User
Posts: 7,977

Re: work library question

Posted in reply to Steelers_In_DC

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.

Valued Guide
Posts: 860

Re: work library question

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.

Super User
Posts: 19,851

Re: work library question

Posted in reply to Steelers_In_DC
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.
Valued Guide
Posts: 860

Re: work library question

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.

Valued Guide
Posts: 860

Re: work library question

Posted in reply to Steelers_In_DC

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.

Super User
Posts: 11,343

Re: work library question

Posted in reply to Steelers_In_DC

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.

Solution
‎01-07-2016 10:58 AM
Super User
Posts: 5,516

Re: work library question

Posted in reply to Steelers_In_DC

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.

Valued Guide
Posts: 860

Re: work library question

Posted in reply to Astounding

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

☑ This topic is solved.

Need further help from the community? Please ask a new question.

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