The SAS Output Delivery System and reporting techniques

timing problems

Accepted Solution Solved
Reply
Contributor
Posts: 73
Accepted Solution

timing problems

I've been running into a number of timing problems with SAS

for example I have some code written by a number of people.  Throughout the code the same temperary file name is used 'temp'

The problem comes up where I get a permissions error in a datastep using temp following a proc sql that creates temp.  Other times temp is reused in several queries inside one proc sql.

I've been solving this by first putting quit;run; in front of the datastep or breaking up the proc sql.  Is there a better way?   IT tells me there are no other processes running on the server that could be interfering


Accepted Solutions
Solution
‎08-19-2013 04:00 PM
New Contributor
Posts: 2

Re: timing problems

wkossack,
from your posting and the verbiage in the log:

ERROR: Rename of temporary member for WORK.TEMPP.DATA failed.                                  

File may be found in C:\DOCUME~1\SAS\LOCALS~1\Temp\SAS Temporary Files\_TD5232.               

I believe this is caused by latency on the disk versus the next thing SAS is doing with the file after writing to tempp.sas7bdat.lck and then trying to rename it from tempp.sas7bdat.lck to tempp.sas7bdat (thus the error in the rename operation).  I have been experiencing this same rename error for the past several weeks and have to come to realize that our IT Department activated BitLock on our Win-7 32-bit laptops (I have no control over the environment, just a user).  The nature of BitLocker is that it purposely "scatters" all of the data across the hard drive versus "concentric" writing in order to obfuscate would be drive hackers (among other techniques BitLocker employs), so with the added overhead in write operations, SAS, in its "need for speed" and opening, writing, closing, renaming, and going on to the next proc or data step, is moving too quickly for the system to keep pace, hence, the rename errors.  We probably don't get this problem with other office applications because we aren't moving along as quickl;y as batched statements in SAS do....  I've been toying with a macro to come behind the last data step (or proc) to test if the *.sas7bdat.lck" of &sysdsn(substring 9-32) is present, and if so to pause 2 sec then issue a DOS rename command.  I'm still testing, but if this is something you'd be interested in I can post the macro here when I think it's ready.

thanks,

John

View solution in original post


All Replies
Super User
Posts: 19,063

Re: timing problems

Is the error at a consistent point?

Can you post the error or log, there's so many things that could be the cause of the error.

Contributor
Posts: 73

Re: timing problems

The error occurs at places where temp file names are reused or the file is accessed in the query or datastep following its creation.  I would like to avoid recoding all the SAS code for a dozen projects and then re-validating the output.

here is an  example the file tempp has been used previously but now it is being reused

MPRINT(QUERY_CK):   ** Combine Queries from PDSR & Site(Assume each response is a new query) **;


MPRINT(QUERY_CK):   data tempp;                                                                 


MPRINT(QUERY_CK):   merge pdsr(in=inpdsr) site(in=insite);                                      


MPRINT(QUERY_CK):   by qainfo_test_set_id qa_seq_num;                                           


MPRINT(QUERY_CK):   if inpdsr or insite;                                                        


MPRINT(QUERY_CK):   if (client_comment ne '' or qa_comment ne '') & not(site_has_mail=0 &       


qa_has_mail=0);                                                                                 


MPRINT(QUERY_CK):   run;                                                                        


                                                                                                


NOTE: There were 272 observations read from the data set WORK.PDSR.                             


NOTE: There were 262 observations read from the data set WORK.SITE.                             


NOTE: The data set WORK.TEMPP has 38 observations and 11 variables.                             


ERROR: Rename of temporary member for WORK.TEMPP.DATA failed.                                   


File may be found in C:\DOCUME~1\SAS\LOCALS~1\Temp\SAS Temporary Files\_TD5232.                


NOTE: SAS set option OBS=0 and will continue to check statements.                               


      This may cause NOTE: No observations in data set.                                         


NOTE: DATA statement used (Total process time):                                                 


      real time           0.01 seconds                                                          


      cpu time            0.00 seconds

Super User
Posts: 19,063

Re: timing problems

Can you run the following code successfully:

data temp1;

     set sashelp.class;

run;

data temp1;

     set sashelp.cars;

run;

Contributor
Posts: 73

Re: timing problems


yes....curious I did not get any rows from sashelp.cars

the problem occurs occationally but enough that I have to log on early in the morning to check the nightly batch and re-run any code that fails

PROC Star
Posts: 1,146

Re: timing problems

Generally, at SAS installation the config files are set up so that every user gets a WORK library that is unique to them. If the config environment has been changed so that users are sharing a WORK library, that could account for this problem. If this is the case, I STRONGLY recomment that you modify the configs to go back to the default, otherwise you will have continual random occurences of this type.

If you run the following statement:

libname work list;

it will show you what directory is being used for WORK.

I can't think offhand of anything else that would account for this. What platform are your users running SAS on?

Solution
‎08-19-2013 04:00 PM
New Contributor
Posts: 2

Re: timing problems

wkossack,
from your posting and the verbiage in the log:

ERROR: Rename of temporary member for WORK.TEMPP.DATA failed.                                  

File may be found in C:\DOCUME~1\SAS\LOCALS~1\Temp\SAS Temporary Files\_TD5232.               

I believe this is caused by latency on the disk versus the next thing SAS is doing with the file after writing to tempp.sas7bdat.lck and then trying to rename it from tempp.sas7bdat.lck to tempp.sas7bdat (thus the error in the rename operation).  I have been experiencing this same rename error for the past several weeks and have to come to realize that our IT Department activated BitLock on our Win-7 32-bit laptops (I have no control over the environment, just a user).  The nature of BitLocker is that it purposely "scatters" all of the data across the hard drive versus "concentric" writing in order to obfuscate would be drive hackers (among other techniques BitLocker employs), so with the added overhead in write operations, SAS, in its "need for speed" and opening, writing, closing, renaming, and going on to the next proc or data step, is moving too quickly for the system to keep pace, hence, the rename errors.  We probably don't get this problem with other office applications because we aren't moving along as quickl;y as batched statements in SAS do....  I've been toying with a macro to come behind the last data step (or proc) to test if the *.sas7bdat.lck" of &sysdsn(substring 9-32) is present, and if so to pause 2 sec then issue a DOS rename command.  I'm still testing, but if this is something you'd be interested in I can post the macro here when I think it's ready.

thanks,

John

Contributor
Posts: 73

Re: timing problems

thanks

we have since moved to a new server running windows 2008 R2 64 bit and the problem has gone away

actually the old server started developing serious problems causing the need to upgrade

PROC Star
Posts: 1,146

Re: timing problems

Wow! Nice catch!

Tom

🔒 This topic is solved and locked.

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

Discussion stats
  • 8 replies
  • 1287 views
  • 0 likes
  • 4 in conversation