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

Programs that were running fine and now taking hours to run.  The problem is restricted to data steps.  My processing is local after the first step when I retrieve a permanent data step via a VPN connection to a central file server.  All subsequent data steps are in the work directory which is mapped to the C drive in my laptop.  Datasteps that were taking 0.04 seconds of real time and 0.06 seconds of CPU time are now taking 5+ minutes of real time and 8+seconds of CPU time.  Something is clearly interfering.  If it were anti-malware or actual malware, it would probably impact both data steps and procedure calls.  So I am thinking that SAS is trying to communicate with the remote file server even though it was not asked to do so.  Any way to check out this theory?  Other solutions?  The files involved are small, and the temporary SAS datasets appear to be of reasonable size.  No sign of exhausting virtual drive space.  Running SAS 9.4 TS Level 1M6. X64_10Pro platform.

1 ACCEPTED SOLUTION
7 REPLIES 7
polarjud
Obsidian | Level 7

Well, that ran at normal speed.  Strange.

 

data class;
  set sashelp.class;

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.01 seconds
cpu time 0.01 seconds

 

polarjud
Obsidian | Level 7

Okay, I figured out the issue.  It was a bad format search.  Thanks for the help, Kurt!

 

polarjud
Obsidian | Level 7

My format catalogs are stored on the remote server.  Is there some easy way to create copies of them in the work library at the start of a job?

 

MargaretC
SAS Employee

Is it just the first Data step (the one that moves data from the permanent SAS data file locally) that is slow?  Or are all the Data steps after you move your data local slow?  

polarjud
Obsidian | Level 7

All of them, but I figured out the issue.  It was a bad format search option.  

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 1225 views
  • 1 like
  • 3 in conversation