Tag Archive for log

AND & OR, a cautionary tale

The inspiration for this post is a situation where having the string “OR” or “AND” as an input to a piece of SAS Macro code breaking a program that I had written. Here is a simplified example of what I was doing:

%macro test;
%let doms=GE GT NE LT LE AND OR;
%let lv_count=1;
%do %while (%scan(&doms,&lv_count,’ ‘) ne );
%put &lv_count;
%let lv_count=%eval(&lv_count+1);
%end
%mend test;

%test;

The loop proceeds well until the string “AND” is met and “OR” has the same effect. The result is the following message appears in the log:

ERROR: A character operand was found in the %EVAL function or %IF condition where a numeric operand is required. The condition was:  %scan(&doms,&lv_count,’ ‘) ne
ERROR: The condition in the %DO %WHILE loop, , yielded an invalid or missing value, .  The macro will stop executing.
ERROR: The macro TEST will stop executing.

Both AND & OR (case doesn’t matter but I am sticking with upper case for sake of clarity) seem to be reserved words in a macro DO WHILE loop while equality mnemonics like GE cause no problem. Perhaps, the fact that and equality operator is already in the expression helps. Regardless, the fix is a simple one:

%macro test;
%let doms=GE GT NE LT LE AND OR;
%let lv_count=1;
%do %while (“%scan(&doms,&lv_count,’ ‘)” ne “”);
%put &lv_count;
%let lv_count=%eval(&lv_count+1);
%end
%mend test;

%test;

Now none of the strings extracted from the macro variable &DOMS will appear as bare words and confuse the SAS Macro processor but you do have to make sure that you are testing for the null string (“” or ”) or you’ll send your program into an infinite loop, always a potential problem with DO WHILE loops so they need to be used with care. All in all, an odd looking message gets an easy solution without recourse to macro quoting functions like %NRSTR or %SUPERQ.

Error: User does not have appropriate authorization level for library xxxx

In a world where write access to a folder or directory is controlled by permission settings at the operating system level, a ready answer for when you get the above message in your log when creating a SAS data set would be to check your access. However, if you are working in Windows and your access seems fine, then SAS’ generation of an access error message seems all the more perplexing. However, unlike the more black and white world of UNIX and Linux, Windows has other ways to change access that could throw things off from the straight and narrow. One of them, it would appear, is to right click on the file listing pane in Windows Explorer and select "Customize this folder…" to change how it appears. The strange upshot of this that a perpetual read-only flag is set for the folder in question and that flag triggers SAS authorisation errors; it’s all very strange and unexpected when you find it and deleting the folder and creating a new one, of course saving anything that you want to retain, is the quickest and easiest solution. In fact, it begs the question as why Microsoft are re-appropriating a flag used for access purposes to be used to determine whether the HTML components of a folder display have been changed or not. This is very strange stuff and does not look like good software design at all. With all the other problems the Microsoft create for themselves, I am not holding my breath until it’s fixed either. There seem to other things like this waiting to catch you out when using Windows SAS and good place to start is with SAS’ own description of the problem that I have just shared.

  • As is commonly the case with places like these, all the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. With regards to any comments left on the site, I reserve the right to reject any that are inappropriate. Otherwise, whatever is said is the sole responsibility of whoever is leaving the comment.