SAS Log doesn't update after ctrl-break stopping

[Peter_C]

Add options at sas session start

-ALTLOG 'relevant server file.log'

-logparm rollover=session write=immediate

then you get a copy of the complete log and as it is unbuffered (imnediate) you get the final lines written with nothing lost in cache

You could add #directives like date and time, to the log file name if you change the rollover option from the default  rollover=NONE

[martha_sas]

Using altlog is a good idea. The addition of the logparm option with write=immediate bypasses the default buffering of the log on Windows so you should get everything, even if the SAS session terminates in an abnormal manner.

The rollover=session parameter isn't needed unless you add some directives to the log file name, in which case the default rollover=none would not resolve the directives. If you use more than one parameter with logparm, the correct syntax would be to enclose all the  parameters in quotes, E.G.

  -logparm "rollover=session write=immediate"

[Peter_C]

Martha

if the sas session fails (syntax check mode or worse) will the TERMSTMT option be ignored?

It just looks like a "final chance" to collect session information.

peterC

[jakarman]

What is happening.....
Ctrl-brk, task manager stop  ||  kill or  other OS commands are instructions to the operatings system to stop something.

If you are having bad luck that can happen in a bad moment an by that losing consistency.

The stop ! etc commands are instructions  to SAS to stop processing. SAS will stop the processing at a seatible moment.

Some instructions to stop processing should be handled with care as they can cause inconsistency of your data.

Suppose the process is wirting data, caching a lot and you stop that without any option to complete something to consistency

You will left with corrupted data. The log file is also cached. A crache of a SAS process may leave that without having all information.

Sometimes you can find some actions to recover something of the bad luck as the link described with some weird actions.

[jakarman]

The altlog is with buffering disabled could be a good for debugging purposes.
As buffering is disabled this can be in turn having the effect of very slow behavior.

The termstmt is something that would be SAS-code only run when SAS is coming to an end. And what when the problem is: there is no end.

It will not help.

In an EIP environment there is already a lot of logging done and that can be extended.

The ARM feature is one that is designed to do Application Resource Measurement. This is standard available in SAS, just coding for usage.     

[bpowell]

Please note this is still an issue. Also worth noting the standard unhelpful responses above "are you sure you should be generating errors"; "are you stopping it correctly"; "what are your system details"; etc.

All of those just indicate the poster is unfamiliar with the issue and add zilch.

Just to add, it can occur (in Windows 10, SAS 9.4 32 bit) whether you interupt with the exclamation mark or by any other way.

I am surprised no one in SAS has encountered this issue and so fixed it, although perhaps they always write error free code and so never need to stop it?

[billcoupe]

Try typing and running the following line:

options notes;

It worked to resolve this for me.  Credit to my colleague Randy Ledbetter for the tip!

[Khan2]

I have noticed this issue as well. Unfortunately, hitting "!" occasionaly to stop the code is unavoidable when you are working with big data. This issue has persisted for almost 7 years now.

[Tom]

This is an ancient thread.  If you have a new question open a new thread. You can link back to this one if it helps explain your issue.

That said the main thing I see missing from this thread is no discussion of the impact of stopping a program in the middle that either turning of writing to the log by change options like NOTES or SOURCE or has redirected the log to another place using PROC PRINTTO.

Someone on this thread mentioned that they run a lot of long running program interactively.  You should probably learn how to run those programs as regular or background jobs instead of using interactive SAS (or even the new pseudo interactive interfaces like SAS/Studio or Enterprise Guide).  Use the interactive tools to develop and test your code on smaller samples of the data.  Then save the program and run it from the command line of via some type of "batch submit" option.

[bpowell]

Well done Tom, a text book example of not even begining to address the question. The thread is ancient because it hasn't been answered / resolved. Imagine this: my brake pedal stops working if I drive at 71mph with the windows down and the manufacturer suggests, a) the speed limit is 70mph and I shouldn't be driving at 71mph and b) consider driving with the windows up above 65.

I run this code frequently (and please don't lecture me why I shouldn't be breaking running code - its quite possible I've been using SAS for longer than you've been alive). Hint, this restores a log that has stopped updating,

King Regards.

/*--------------------------------------*/
/*!!!Kill this code during the export!!!*/
/*--------------------------------------*/

data temp;
do i=1 to 1000;
x=1;
output;
end;
run;

proc export data = temp outfile="c:\temp\temp.xls" replace;run;

[Tom]

Not sure I understand your comment (either part).

Are you saying the thread is not from 9 years ago with the most recent posting 4 years ago?

Are you saying that just interrupting a PROC EXPORT will cause the SAS session to start writing to the LOG again?  Or did you mean that interrupting a PROC EXPORT is your suggestion of why the original poster (or perhaps this new poster)  had their SAS log stop updating?

Either way that is interesting idea but I am not how.  Perhaps somehow during the PROC EXPORT SAS is changing some setting that users cannot change directly and interrupting it causes it skip the step that sets it back to normal?

[bpowell]

Apologies for my slightly cheeky reply and thank you for your good humour.

Interrupting the export does indeed rekindle a frozen SAS log in 9/10 occasions. Afraid I have no idea why it works but it does. I understood it was something to do with pinging the ODS system.

Yes the thread is old, but then it has not been resolved, so it is relevant I think to keep it open.

[Tom]

But what does pinging the ODS system have to do with whether or not the SAS log is getting updated?

[bpowell]

Something about proc export, which uses ODS under the hood (so I understand) writes to the log in such a way that it bypasses whatever it was in the log break routine that has failed when killing code. Again, this only happens in some cases - sometime if you kill code it dies gracefully and the log is unimpacted. When it does stop updating, there is something about interupting the call to ODS in an export statement that manages to restart the log write.