Even the best programmers make mistakes. For most errors, SAS software displays the nature and location of the error, returns control to the programmer, and awaits further instructions. However, there are a handful of insidious errors that cause SAS to think that a statement or program is not finished. For these errors, SAS doesn't display the error because it is waiting for the programmer to finish submitting the rest of the statement. Meanwhile, the programmer (who is unaware that an error has occurred) is waiting for SAS to respond. From the programmer's point of view, SAS is frozen. It has gone off into La-La Land, or maybe the Twilight Zone.
Fortunately, there is a simple "magic command" that fixes them all of these common errors. The common errors that render SAS unresponsive are as follows:
- The forgotten semicolon: If the last statement in a program does not contain a terminating semicolon, SAS thinks that the program is not finished. It waits to receive the rest of the statement. Without a terminating semicolon, SAS will wait, and wait, and wait....
y = 1 /* No semicolon, so statement not complete */
-
The forgotten closing single quote: If your program starts a string but forgets to end it, SAS thinks you are in the process of defining a string. You can submit statements such as QUIT and ENDSAS, but SAS thinks these statements are just part of the string and does not execute them.
As shown above, you can detect this error visually if you are using a program editor in which syntax is color-coded. For example, in the SAS enhanced editor, all characters after the equal sign are colored purple, which indicates that SAS thinks they are all part of a string. Also, after the character string exceeds 256 characters, SAS writes a helpful warning to the SAS Log:
c = 'My string; /* No closing quote. Future stmts are part of string */ run; * Hey! SAS is frozen! ; endsas; * Argh! Nothing works! ;WARNING: The quoted string currently being processed has become more than 262 characters long. You might have unbalanced quotation marks. - The forgotten closing double quote: Same issue as for the forgotten single quote.
- The forgotten closing comment: You started a comment, but haven't closed it with */. No matter what text you submit, SAS thinks it is part of the comment.
Again, if you use a color-coded program editor, you ought to be able to detect this error visually. In the SAS enhanced editor, you will notice that your statements are green.
c = 'My string'; /* Program is complete run; * Hey! SAS is frozen! ; endsas; * Argh! Nothing works! ;
There is a "magic command" that you can submit that will recover from all four errors:
;*';*";*/; |
If you have used SAS Enterprise Guide, you've probably seen this special statement (also called the "magic string" or the "quote killer") appended to the end of submitted programs. It is used by many client applications to ensure that the SAS server terminates and produces results such as ODS tables and graphics. I don't know who originally invented the magic command, but let's look at what it does:
- If the submitted program is already properly terminated (none of the errors are present), the command issues a null statement (the first character) and a comment (the remaining characters).
- If the submitted program forgot a concluding semicolon, the command terminates the previous statement (the first character) and issues a comment (the remaining characters).
- If the submitted program forgot to close a single-quote string, the command terminates the string (the third character) and issues a comment (the remaining characters).
- If the submitted program forgot to close a double-quote string, the command terminates the string (the sixth character) and issues a comment (the remaining characters).
- If the submitted program is missing a closing comment symbol, the command closes the comment (the eighth and ninth characters) and issues a null statement (the last character).
In all cases, the magic command causes SAS to escape from La-La Land and returns control to the programmer.
A forgotten RUN or QUIT statement is another error that can cause SAS to be unresponsive. For most procedures, SAS parses the statements in a program, but does not execute them until it encounters a RUN or QUIT statement. (Exceptions include some interactive procedures such as the IML and SQL procedures.) This kind of programming error is obviously fixed by submitting a QUIT or RUN statement. (Some programmers use the RUN CANCEL statement to abort a submitted DATA step.) Consequently, some programmers might want to modify the magic string as follows:
;*';*";*/;quit; |
Again, this version of the magic command is used by many SAS client applications, including EG. It looks mysterious the first time you see it, but after you dissect it, it makes perfect sense. If you have ever asked "what is the purpose of the statement at the end of SAS Enterprise Guide programs," now you know!
Do you have a debugging tip that you use to overcome an insidious error? What do you do to regain control when your SAS program contains an error that locks-up your computer? Leave a comment.
29 Comments
Should the magic string contain a %mend; as an unterminated macro may also land you in the Twilight Zone?
No. The thing about the magic string is it is safe to use even when there are no errors. Althoug a missing %mend will cause problems, inserting a %mend when you are not defining a macro is iteself an error.
I had the freezing problem inside a macro definition. The magic string on its own did not thaw SAS. After some slash-and-burn debugging I eventually discovered a single quote lurking in a macro-style %*; comment.
Yes, I know the documentation warns about this. However, it is natural to write comments in English containing possessive apostrophes. Why doesn't the syntax highlighter spot this?
Maybe I should forget about *; and %*; comments, but I can comment out sections of code containing them with /**/. Now if I could nest /**/ that would help.
I recall fondly using this in SAS version 6.12 days when there was no color coding. Got me out of the Twilight Zone quickly without having to resort to ending my SAS session and losing the library connections, macro definitions and macro variables etc. ;-)
I was also happy to see the statements included after user-written SAS code in SAS Enterprise Guide.
1/ You will find this "magic string" often in Eguide remote processing logs.
Good this is documented now, in a blog.
2/ Macro comment the %* is a behaving a little bit different. See:
http://support.sas.com/kb/32/684.html
http://support.sas.com/documentation/cdl/en/mcrolref/62978/HTML/default/viewer.htm#p030uw6k2s7wzyn18i9obutg923m.htm
At some time I mixed the type of comments and got into word / text scan issues. They are different between sas/macro and normal sas language.
Not a big issue when recognized. But before it get being recognized.
Thanks for the link. Yes, defining a SAS macro comes with its own set of potential errors and caveats.
I have faced this issue in the past, and i overcome it by disconnecting my SAS. This is really helpful and saves a lot of effort.. thank you.!
I want to remove "WARNING: The quoted string currently being processed has become more than 262 characters long. You might have unbalanced quotation marks." from my log.
I have used magic command, just applying at start of my program ;*';*";*/;
But it's not working, Could you please give some example, how to use this command?
Thanks in Advance.
Submit the "magic string" after you get the warning. This will terminate the string with unbalanced quoates and return you to "parsing mode." To get rid of the warning, you need to find the unbalanced string. There is not an automatic way to do this. I would use a text editor to find every occurrence of double quotes ("). Every time you use quotation marks to create a string, make sure that the string is properly terminated.
Hi Rick and others,
Long time listener; first time caller here.
I'm running SAS 9.4 for Windows (64-bit). When executing SAS programs in batch mode, if the program includes a PROC UNIVARIATE procedure with a HISTOGRAM statement, I consistently see the following quirky behavior. The execution of the program appears to pause in order to display each histogram in a pop-up window. When I click on the histogram, it vanishes and the execution of the program appears to resume. I don't believe that I've seen this with other types of ODS graphical output.
I'm a histogram kind of guy, so this issue prevents many of my programs from running unassisted in batch mode.
Batching and bewildered,
Eric
You mention ODS, but I don't think you are using ODS graphics. This sounds like the traditional graphics being run in noninteractive mode.
If you want ODS graphics, put
ODS GRAPHICS ON;
at the top of your program.
If you want traditional graphics but do not want the graphs displayed on your monitor, put
GOPTIONS NODISPLAY;
at the top of your program.
My mistake--you're exactly right. By turning ODS graphics on, I no longer get the pop-ups during batch mode. Thanks.
SAS not responding when i submit for analysis, i tried alot it every time get hanged so i installed it again one day it worked welll but again it got held. what to do with it. please help me.
Regards
Muhammd Imran
Sorry to hear. Make sure there is a RUN statement at the end of the lines you are submitting. If you are using SAS University Edition, submit your problem to the SAS UE support community. Otherwise, describe your problem in one of the other SAS Support Communities. Be sure to provide the code and submit the SAS log.
Where the "magic string" should be submitted from if SAS is frozen?
In this post, "freeze" is in quotation marks because SAS isn't actually nonresponsize, but is merely awaiting the closing of a string, comment, or other statement. If SAS is truly unresponsive/frozen, then obviously you cannot submit any string, "magic" or otherwise. In that case, interrupt computations by pressing the Break icon, if it is available. In extreme cases, you might have to kill the SAS process from the operating system.
Hello, I have a problem I want to work with a database of 25000 cases, and SAS, although I read the base, when I ask for an analysis, I run but I do not get the results, and it gives me these two messages
The following page has become unresponsive you can make it responsive or kill it
The size of the results is greater than 4MB. Insufficient memory could cause performance problems or an error. Do you want to display the results anyway?
What would be my problem?
I do not know, but you can post your code to the SAS Support Communities and describe what you are trying to accomplish.
I've just tried the magic string and I can categorically state that it does not work. I'm trying to fix a combined "The meaning of an identifier after a quoted string might change" and the "The quoted string currently being processed" warning and it does absolutely nothing.
Those error messages are caused by having one or more strings that do not have closing quotation marks, such as
x = "Joe;
or
y = 'Fred;
Sometimes the only solution is to manually search for quotation marks until you find the one that is not part of a matching pair.
Procedures in SAS 9.4 freeze when there is a typo, e.g., in a variable name. SAS says "Processing submitted statement" and the Break icon usually does not respond or responds very slowly. The data set I am currently working with is quite large - ab 1 million records, although I had similar problems with much smaller datasets and with SAS 9.3. It has been going on for > a year. I contacted SAS about this and other problem, had SAS reinstalled, as they recommended, but it did not solve the problem with freezing. Things are usually better at the beginning of SAS session and quickly getting worse over a couple of hours or less, even though I regularly clear log and results window. The severity of the problem depends on the time of the day and it is better after hours, although SAS is locally installed and the data are stored locally too. I intentionally do not use work library, partially b/c it is on the network (out IT department chose it as a default) . So far only killing SAS works, but I have to do it every 30-90 minutes. I often use HTML output, I know it makes SAS work slowly, but I am not sure about the connection btw the output type and the Break icon performance . Why does it happen and what can help? . Thank you
I cannot tell from your description. Your best bet is to send your program to SAS Technical Support. Be sure to specify your interface (DMS, EG, SAS Studio) and where the SAS workspace server is (Local, remote, grid,...) Two possible things to check: (1) make sure interactive procedures (eg, REG, GLM, DATASETS,....) are terminated by a QUIT statement, not by a RUN statement. (2) Make sure that you are opening/closing ODS destinations correctly. (3) If you are generating a lot of output, a lot of graphs, or a lot of messages to the log (for example, you are running a macro loop), then see the ideas in the article "Turn of ODS when running simulations."
I found this blog whilst looking for when EG freezes - but thanks those chars in EG makes sense now
In SAS Base. We sometimes lose the LOG if the break key is hit especially during PROC SQL. To get the LOG back, run a simple data step with a sleep command set at 5, hit the break key again during the sleep, you get the log back.
Wow, thanks for the tip, Jon. I've never heard that one before!
We run lots of multi-step SQL (create temp table, create second table by joining to first, drop first, repeat) and some steps may take a while to complete, in a program that may take hours.
In PC SAS, the log was visible while running. It may not have been the intended purpose, but it was an acceptable "progress meter" - keep glancing at the log to make sure line numbers are steadily getting bigger.
EG doesn't appear to show the log as it runs, unless there's an option we're missing. Is there a way to show the log as the program runs, so we can see steps are being completed and the job isn't just hung?
I don't have experience with this myself, but Chris Hemedinger wrote a blog post about tracking progress in SAS programs. His example includes a PROC SQL step.
Hey, thanks Rick! I'll take a look.
Is there any "magic keystroke" equivalent when "Not Responding" happens during a VIEWTABLE execution?
I just wrote a bunch of code that I'll have to rewrite from scratch if I can't figure out how to escape out of the frozen / grayed out screen state.
I'm more or less (less) resigned to this right now but it would be nice to have a better choice next time this happens.
Sorry for your loss. I have never seen this, but I suspect that if a graphical or tabular window freezes, you probably cannot type any keys. You might want to check out SAS Studio, which is the official interface for modern versions of SAS and has its own table viewer.