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
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.
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.
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.
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.
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.
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.
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.
That makes sense. Learned a lot in this thread. Thank you everyone.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
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.