11-06-2018
PJB
Fluorite | Level 6
Member since
10-12-2017
- 5 Posts
- 2 Likes Given
- 0 Solutions
- 0 Likes Received
-
Latest posts by PJB
Subject Views Posted 2582 08-28-2018 10:04 AM 2615 08-28-2018 03:24 AM 2660 08-27-2018 02:59 AM 2720 08-26-2018 03:04 AM 1222 08-26-2018 02:44 AM -
Activity Feed for PJB
- Posted Re: Update macro symbol table inside data step on SAS Programming. 08-28-2018 10:04 AM
- Liked Re: Update macro symbol table inside data step for Quentin. 08-28-2018 09:52 AM
- Posted Re: Update macro symbol table inside data step on SAS Programming. 08-28-2018 03:24 AM
- Liked Re: Update macro symbol table inside data step for ChrisNZ. 08-28-2018 02:45 AM
- Posted Re: Update macro symbol table inside data step on SAS Programming. 08-27-2018 02:59 AM
- Posted Update macro symbol table inside data step on SAS Programming. 08-26-2018 03:04 AM
- Posted Re: GLOBAL SAS macro var on SAS Programming. 08-26-2018 02:44 AM
-
Posts I Liked
Subject Likes Author Latest Post 1 3
08-28-2018
03:24 AM
Thank you ChrisNZ, this seems to work for what I would like to do. To provide some additional detail: I have a dataset that contains a column with variable names and a column with variable lengths, and I would like to use this to generate dynamic length statements, preferably in a single macro call (so no prior initialization required). This is why it is of no use to retrieve values into data step variables (they basically already are, and these cannot be used in length statements) or to include another data step boundary.
... View more
08-27-2018
02:59 AM
The point would be to do other things that the %put to these macro variables to return dynamic data step statements. The problem is that the macro variables are *not* loaded into the local symbol table. If I execute the code I posted I get the following behaviour: In the first call &sex gives a 'reference not resolved' warning. When the data step finishes however the macro variable is written to the GLOBAL symbol table (although the call symputx was specifically to local). You can %put &sex in open code and you'll get "M". All next calls will reference this global variable, which is no longer modified by the macro. Running %TEST(Carol) in subsequent data steps will always still return Alfred's "M". If I make call symputx address the global symbol table the reference will remain to the value returned from the previous data step, but at least now it can be updated in the global symbol table. That is, if I then add %TEST(Carol) twice in a data step each, the first will return Alfred's "M", the second "F" (which was set by the first %TEST(Carol) call). Would there be a way to have access to the value for &sex in the current data step?
... View more
08-26-2018
03:04 AM
Hi all, I would like to update the macro symbol table inside a data step. Specifically, something like this: %MACRO TEST(name);
rc = dosubl("
data _null_;
set sashelp.class (where=(name eq '&name'));
call symputx('sex', sex, 'l');
run;
");
%put &sex;
%MEND;
data _null_;
%TEST(Alfred);
run; While running %TEST I would need any macro variable created by DOSUBL (or perhaps another method?) available in the (local) symbol table without halting the _null_ data step, I do not want this in a data step variable. From reading http://support.sas.com/kb/53/059.html it appears that this may not be possible? Or is there another way?
... View more
08-26-2018
02:44 AM
It depends... If you run this in open code, then both macro variables will be in the global symbol table. If you run this inside another macro, the variable created by code1 will be local to the symbol table of that macro, whereas code2 will always put the variable in the global symbol table. If you would remove the global statement from code2, the variable would become local to %mmacro, like the variable created by code1 would be local to any macro it's ran from. Also keep in mind that you're assigning the same variable (lastDEC) twice, the second time specifically global, which apparently results in an error if this variable already exists in the local but not global symbol table. Moreover, since lastDEC would already exist in at least whatever symbol table code1 would run from, code2 will reassign this macro variable and not create a new one in the %mmacro local symbol table.
... View more