3

The SAS v9.4 documentation lists an automatic macro variable &sysodsescapechar which contains the current ODS escape character, assigned using ods escapechar=.

Whenever I try to view the macro variable using a %put statement, I get the following error:

ERROR: Open code statement recursion detected.

This happens when open code erroneously causes a macro statement to call another macro statement.

I've tried all of the following:

%put &=sysodsescapechar.;
%put %nrbquote(&sysodsescapechar.);
%put %superq(sysodsescapechar);

They all result in the same error.

When I try to view the macro variable using a data step, it appears to be empty.

data test;
    esc = "&sysodsescapechar.";
    put esc=;
run;

If the macro variable actually is empty, why do I get open code statement recursion errors? The %put statement on its own is valid, so putting an empty variable shouldn't be an issue.

Any guidance here would be much appreciated.

Alex A.
  • 5,466
  • 4
  • 26
  • 56

1 Answers1

2

What's happening is the escape char seems to need a close parentheses. For example:

%put %superq(SYSODSESCAPECHAR););

;

It escapes the ) , which means now you have

%put superq(;);

In your first example, it's a little trickier because a semicolon by itself doesn't seem to be escaped so you have to provide a close parentheses:

%put &SYSODSESCAPECHAR.)x;

x

That works, for example. I'm not sure if it's only close paren or other things that would also allow it to stop trying to escape, but that's the only thing I can tell works.

You can look at the actual value of the macro variable in SASHELP.VMACRO; it's not ' ' (which is indeed what gets passed to the data step even with SYMGET, but it's clearly parsed). In that table it is '03'x, which looks like a uppercase L in the upper half of the character. That is the "End of Text" control character. I suspect the behavior in the editor when using this in text (in a macro variable) is simply a behavior of the editor - '03'x is not representable on many editors (if I try to paste it here, for example, it isn't displayed, but does exist as something I can backspace over with zero width). SAS is clearly capable of dealing with a 'normal' ods escapechar but isn't capable of dealing with '03'x in the same fashion.

Joe
  • 62,789
  • 6
  • 49
  • 67
  • Thanks, Joe. Something to note is that if I assign the ODS ESCAPECHAR to something other than the default, which you pointed out is '03'x, using `%superq(sysodsescapechar););` gives me an error on the second close paren. Also, if I use something other than the default, I get no recursion errors with my original statements. – Alex A. Feb 09 '15 at 17:48
  • Also it amuses me that SAS isn't capable of dealing with '03'x as you said, yet it's the default escape character... – Alex A. Feb 09 '15 at 17:51
  • Of course if it's assigned to something you get an error on the second close paren; you could do something like `%put %superq(sysodsescapechar);*);` (add an asterisk, which becomes a comment if it is defined properly). SAS of course can handle '03'x in the SAS engine - it's the editor that isn't handling it properly, I believe. – Joe Feb 09 '15 at 17:54
  • Wouldn't it be the log that isn't handling it properly? Why the editor? – Alex A. Feb 09 '15 at 17:58
  • No, the log is not capable of generating errors in and of itself. I probably shouldn't say editor, as technically the editor doesn't see the symbol; it's probably the macro processor which is being tripped up. I don't know for sure. But it's something at or before the SAS language compiler, and my feeling is that it's not the language compiler itself - it's the word scanner or the macro processor, most likely, one or the other not handling the '03'x character properly (or handling it the way it's supposed to be handled - that is a control character so there may be some old mainframeness). – Joe Feb 09 '15 at 18:04
  • Okay. Thanks for all of the information. As always, it's much appreciated. – Alex A. Feb 09 '15 at 18:07