Macro variable scope

Accepted Solution Solved
Reply
Occasional Contributor
Posts: 15
Accepted Solution

Macro variable scope

[ Edited ]

Hi guys,

 

Here is a weird thing I observed. Any help would be appreciated. In below code myvar is retained outside of macro call. But myvar2 is not retained(resolved). (I tried it on PC SAS no unix)

 

 

%macro test1();
data _null_;
call symput('myvar',"value resolved");
run;
%mend test1;
%test1;
%put &myvar;
 
%macro test2(param1);
data _null_;
call symput('myvar2',"value resolved");
run;
%mend test2;
%test2(parvalue);
%put &myvar2;

 


Accepted Solutions
Solution
‎07-09-2017 04:29 PM
Super User
Posts: 5,353

Re: Macro variable scope

[ Edited ]

There's a funny rule that accounts for this funny behavior.

 

CALL SYMPUT never puts a macro variable into an empty symbol table. Instead, it puts the macro variable into the closest "non-empty" symbol table. 

 

(Technically, there's no such thing as an empty symbol table ... the symbol table just doesn't exist at all.  But the first paragraph is the way it's usually written up in the documentation.)

 

So when the first macro runs, there is no local symbol table.  CALL SYMPUT creates a new macro variable and is forced store it in the global symbol table.

 

When the second macro runs, there is a local symbol table, since parameters on the %MACRO statement are always local.  Therefore, when CALL SYMPUT creates a new macro variable, it gets stored in the local symbol table.

 

If you want your macro variables to be global,  you can achieve that by switching to CALL SYMPUTX:

 

call symputx('myvar', "value will resolve this time", 'G');

 

The value of the third parameter (G) tells the software to use the global symbol table.

View solution in original post


All Replies
Solution
‎07-09-2017 04:29 PM
Super User
Posts: 5,353

Re: Macro variable scope

[ Edited ]

There's a funny rule that accounts for this funny behavior.

 

CALL SYMPUT never puts a macro variable into an empty symbol table. Instead, it puts the macro variable into the closest "non-empty" symbol table. 

 

(Technically, there's no such thing as an empty symbol table ... the symbol table just doesn't exist at all.  But the first paragraph is the way it's usually written up in the documentation.)

 

So when the first macro runs, there is no local symbol table.  CALL SYMPUT creates a new macro variable and is forced store it in the global symbol table.

 

When the second macro runs, there is a local symbol table, since parameters on the %MACRO statement are always local.  Therefore, when CALL SYMPUT creates a new macro variable, it gets stored in the local symbol table.

 

If you want your macro variables to be global,  you can achieve that by switching to CALL SYMPUTX:

 

call symputx('myvar', "value will resolve this time", 'G');

 

The value of the third parameter (G) tells the software to use the global symbol table.

Occasional Contributor
Posts: 15

Re: Macro variable scope

Thanks for your reply. I understand now what is going on. But it still sounds haphazard behavior on the part of SAS. I would expect better.

 

Thanks again.

 

 

PROC Star
Posts: 1,669

Re: Macro variable scope

This is neither good or bad. It's just a design decision. The variable could go to the most local table, or to the global one. Would that be better? Maybe. Maybe not. Which of the two would be better? Local? Global?

At least you have a choice here.

Occasional Contributor
Posts: 15

Re: Macro variable scope

I appreciate your taking time to reply, but I don't agree with you. The same code should not behavie differently, just because you have a parameter in the macro definition. I think it is a bad design.

 

But anyways.. I now know what the problem is so corrected my code.

 

Thanks,

PROC Star
Posts: 1,669

Re: Macro variable scope

The only way achieve this would be to have to no scopes, and that all variables be global.

As soon as you have scopes, behaviours will change depending on where variables are defined.

☑ This topic is solved.

Need further help from the community? Please ask a new question.

Discussion stats
  • 5 replies
  • 393 views
  • 5 likes
  • 3 in conversation