Is there something going on with SAS OnDemand today? When running a script on SAS OnDemand for Academics which I've successfully run several times before, I am not getting any results, but am instead presented with a long log file which essential re-states by script prepended with 70 lines that start
1 OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK; 2 TITLE; 3 FOOTNOTE; 4 OPTIONS LOCALE=en_US DFLANG=LOCALE; 5 DATA _NULL_; 6 RUN;
When I try to run a simple import
FILENAME REFFILE '/home/u50257852/FSS_Dashboard/Import/FHC_OCHIN_Screening_and_Follow_Up.xlsx'; PROC IMPORT DATAFILE=REFFILE DBMS=XLSX OUT=WORK.EPIC_OCHIN_Import; GETNAMES=YES; RUN;
I'm again presented with a long log which begins: "
NOTE: The quoted string currently being processed has become more than 262 bytes long. You might have unbalanced quotation marks. 1 OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK; 2 TITLE; 3 FOOTNOTE; 4 OPTIONS LOCALE=en_US DFLANG=LOCALE; 5 DATA _NULL_; 592 &GRAPHTERM; ;*';*";*/;RUN;QUIT; _________________ 49
If I enter nonsense
proc sql; select * from table; quit;
I get exactly the same response.
Thank, tomrvincent. I did look at the related topics and didn't find anything helpful. Most referred to macros which neither my initial file nor the test files include.
It is very irritating. Thank you for your guidance. I didn't find a quote that wasn't closed, but, after restarting, I copied my code into a new file piece-by-piece and tested it along the way.
The only cause I can possibly identify is that I had a series of %web_drop_table statements at the head of the script. Maybe that's what cause SAS to choke with a meaningless error.
In my experience this message is mostly caused by SAS users not following correct SAS syntax. It's pretty difficult for code parsers to gracefully deal with all of the possible ways users get their syntax wrong. Most of the time this note warns correctly - there is an unmatched quote somewhere and you need to fix it. So hardly a bug in my opinion.
The bug is in the user's code. Any sufficiently bad code can bring an interpreting language system out of sync that does not completely reset itself with every submit.
The SAS interfaces (Studio and EG) try their very best to correct such mistakes with the "magic string" sent after each submit, but there are conditions where multiple issues (e.g. an open macro definition, with %mend missing or overridden by unbalanced quotes) cause that not to work as intended, and then you need to reset the session.
For what it's worth, and because it might help someone else Googling this same error, I have a problem with long labels in some generated code. The code runs just fine until the program file is %included. Then I get this error same error. The generated labels are clearly longer than the allowed 256 characters, but SAS seems to deal with it ok by simply truncating the labels, until the file is %included when at some point it just gives up and never finishes executing the data step.
The fact that you keep trying to sugarcoating the issue is actually a perfect reflection or mirror of how SAS company and its tech support deals with problem- Blaming the victims.
If you ever look at other interpreter like Python, you would know that it IS the responsibility for an interpreter to accept whatever code user submitted no matter good or bad. It can respond with error message but should recover when the erroneous code is gone. While for SAS interpreter, it just cannot get itself out from the 'bad code' in this scenario. There is no excuse for such interpreter bug, it is something they should have fixed long time ago.
@shenzj1994 wrote:
The fact that you keep trying to sugarcoating the issue is actually a perfect reflection or mirror of how SAS company and its tech support deals with problem- Blaming the victims.
I think there is a limit in comparing SAS to Python, because I regard SAS not strictly as a language, but rather as a tool that looks like a language.
Even so, I take no side on the degree of unacceptability this problem represents in the SAS interpreter.
But my experience with SAS does NOT support the contention that SAS tech support deals with problems by "Blaming the victims". That is a generalization that would require a far broader range of examples.
All software tools have both strengths and weaknesses. Perhaps there is a case to argue that SAS could do better in trapping invalid syntax. However if you compare pretty much any SQL tool with SAS, SAS does a WAY BETTER job of identifying syntax errors than those do. I can't compare SAS with Python as I've never used it.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.