authorization level for library WORK. Dropped in middle of loop

[Pinegulf]

Good day,

I have persisting, and annoying, little problem; My code loops loops number of countries through a macro loop;

%macro do_stuff(country);

... /*Some computations */

%mend;

%do_stuff(UK);

%do_stuff(FR);

%do_stuff(AT);

/*And so forth*/

Now every now and then. (Maybe once a month) In middle of the loop I get error 

Quote;

ERROR: User does not have appropriate authorization level for library WORK.

/quote

Now this is very puzzling since prior loop had all the access and suddenly it got revoked. As far as I can see, it does happen in particular country or datafile. 

I'm running on windows platform and sas version is 9.4. No, the whole code is not for review, but any help would be greatly appreciated. 

Many thanks.

[Kurt_Bremser]

This: https://communities.sas.com/t5/Base-SAS-Programming/Error-User-does-not-have-appropriate-authorizati... could be helpful, especially the reference to http://support.sas.com/kb/40/459.html

[Pinegulf]

Thanks for the input. Only antivirus software running is windows' own. (Since they are virtual machines.) Gotto keep digging.

[Kurt_Bremser]

Note 40459 is specifically naming MS Security Essentials and MS Forefront, so you should look if one of those is active on your VMs.

Yet another thing I never have to worry about (our SAS server runs on AIX).

[avi_gil_chaitovsky_anthem_com]

Workaround suggestion below.

Coming 7 years after the original question, but my Googling got me here, so maybe others are still experiencing the same issue.  Also finding this with running nested loops.  Using SAS Studio, which is running off a Windows machine (I believe Windows Server 2022).

Microsoft Security Essentials, mentioned in the Usage Notes (38896 & 40459) has been deprecated, but likely other antivirus/security software is still the culprit.

Not sure how far I'll get with corporate IT on getting them to turn off antivirus anywhere.

As a workaround, I created a folder and set a different libname (WORK2), and then I explicitly send all the outputs in my loop to WORK2.  At the end, I'll manually delete everything in that folder.  But since it's not stored in the same area of the disk, it looks to not get locked as quickly, and my loop ran.

[Tom]

You might want to look into using the USER settings in SAS.  The basic idea is that if you have defined a libref named USER then single level dataset names will be referenced as USER.dsname instead of the default of WORK.dsname.   That way you do not need change any of your code.  (Unless you have accidentally coded WORK.dsname instead of just dsname.)

Take an example program like this:

data class; 
  set sashelp.class;
run;

Which normally works like this:

1    data class;
2      set sashelp.class;
3    run;

NOTE: There were 19 observations read from the data set SASHELP.CLASS.
NOTE: The data set WORK.CLASS has 19 observations and 5 variables.
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds

But if you have USER libref defined then instead the result is:

4
5    libname user 'c:\downloads';
NOTE: Libref USER was successfully assigned as follows:
      Engine:        V9
      Physical Name: c:\downloads
6    data class;
7      set sashelp.class;
8    run;

NOTE: There were 19 observations read from the data set SASHELP.CLASS.
NOTE: The data set USER.CLASS has 19 observations and 5 variables.
NOTE: DATA statement used (Total process time):
      real time           0.01 seconds
      cpu time            0.01 seconds

There is now a USER system option that lets you substitute some other libref instead of requiring you to define the USER libref.

[Tom]

Another possibility instead of some process like virus scanners locking the WORK directory is that you have a flaw in the logic that generates the WORK directory name such that a new SAS process occasionally starts up that is run by a different user with different access rights and replaces your WORK directory.   I believe the WORK folder name is constructed from the process id.  So perhaps the same process id was assigned to a new SAS session, which might happen if you are sharing the same work disk with multiple servers.  On Unix in that situation SAS will include the server name as part of the name of the work folder to avoid conflicts.

[avi_gil_chaitovsky_anthem_com]

Thank you, @Tom!  I was not aware of the USER option, and this is probably a better solution than what I implemented.

re: your second point about the WORK directory being replaced, it doesn't look like the files disappear when this happens, so I don't think that's the culprit.