03-27-2018 04:35 PM
Has anyone had experience with a SAS job running interactively GUI hang up and not be able to cancel submitted statements or halt the datastep when it appears to stop processing. We are running an FTP step prior to this and it looks like all of the data is read in and it continues on to the data step but then stops. Currently running in SAS 9.4 TS1M2 running on a Windows PC with Windows 7 Professional 64 bit OS, 8GB memory. I am totally unable to view the LOG (just disappears) and cannot switch between windows either. I end up having to close SAS completely down from the Task Manager and have to do manual cleanup of SAS work files.
Thought I would check with folks here to see if there are any suggestions. I've checked memory usage on system and we have 6GB free at time it stalls. Also rebooted to make sure there was no memory leak or anything else going on in background.
03-27-2018 05:02 PM
By "running an FTP step prior to this" do you mean that you are connecting to an FTP service using something like a SAS filename to read or write something?
If so, are you sure that step completed? If you are running this interactively then do not submit the bit of code that does anything after using that filename. Network connections be what they may be it could be something in that connection taking a long time.
It may help to show the code you are submitting. Replace any sensitive information such as url and user/password with something like XXXX.
If you are reading with a data step using the FTP as the infile you might try add the option obs=10 to restrict reading only 10 records from the file to see if that works. If the file is large and the connection slow a data step could take a long time. If the program isn't generating errors then there wouldn't be anything added to the log until the data step completes generally.
"Unable to cancel" might partially be because the system is busy enough running the code that getting an interrupt into the queue is hit or miss. I have written some code with infinite loops that took many tries to get a cntrl-break into the processing cycle before halting the program.
03-27-2018 05:49 PM
03-27-2018 06:29 PM
Since you say that %include file contains macro code we now have a starting point. The behavior you describe is not uncommon for some types of macro problems.
With an interactive session I would open that %included source file and run one step at a time, macro definition, macro call, data step, procedure. That should identify a step that caused things to blow up. Then start with the fine tooth comb in that step for problem causers.
Before executing any macros, especially if these are new or modified from existing ones, I would be tempted to turn on the system options MPRINT SYMBOLGEN and possibly MLOGIC if you have lots of macro logic statements.
As far at the disappearing log is there any chance that the code codes any commands to clear the log?
I would also be tempted to use Proc Printo to direct log output to a file.