SAS processing hangs

[MaryPet123]

 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. 

Thanks all 

Mary  

[ballardw]

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.

[MaryPet123]

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?
Correct. We connect to FTP and read data file from mainframe. The FTP process ends (can tell this both by the data step change on SAS PC as well as the fact that the OMVS segment on mainframe is disconnected). Once it ends it starts the next datastep processing, at that point I see no more activity in the SAS Work files and the log 'just disappears'. I cannot break the stream either, so I have to force close with task manager and manually clean up SAS Work files.

If so, are you sure that step completed?
Yes - see above.

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.
Have tried that as well and have verified that the network connection to the mainframe has closed SUCCESSFULLY from the mainframe. Now we have had this issue with SAS getting hung before but I could always 'Halt Datastep' and get the process to kick back in running. I have not been able to do this at all with this run. I have others that work MUCH better with MORE data processed. So I am at a loss here.

It may help to show the code you are submitting. Replace any sensitive information such as url and user/password with something like XXXX.

libname pdb "D:\Customers\&cust.\&sysid.\&wk.&pt.";
run;

/* input files are SIRMKP.SMFDBWK.IP02 and SIRMKP.SMFDB.IP02*/
FILENAME SMF FTP ("'FILENAME1.FILENAME2. TEMP'")
USER='UID' HOST='XXX.XX.XX.XXX' DEBUG
S370VS RCMD='SITE RDW;SITE READTAPEFORMAT=S' LRECL=32760
PASS='YYYY';

%INCLUDE SOURCLIB(TYPSDB2); /* macro SAS code called to run */
run;

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.
Not using an INFILE statement. This is a variable block spanned record.
If the file is large and the connection slow a data step could take a long time.
We have larger files that process successfully
If the program isn't generating errors then there wouldn't be anything added to the log until the data step completes generally.
Understand but there IS something in the log during the run and then it all disappears. It was there and is lost after it hangs. Where does it go?

[ballardw]

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.