DATA Step, Macro, Functions and more

avoiding macro conflicts

Accepted Solution Solved
Reply
New Contributor
Posts: 2
Accepted Solution

avoiding macro conflicts

I'm starting to explore the idea of creating a set of reusable macros to perform some common tasks at my workplace. Particularly data-restructuring tasks where an input table is given to the macro, which performs several intermediate steps to generate the desired output table.These macros would be called by larger programs. Ideally, I'd create custom Procs for these tasks, but my site doesn't license SAS/TOOLKIT. I'm using Base SAS 9.2.

 

Can anyone share some resources related to ensuring that macros operate within a "sandbox"?

 

My concern is that I will forget which datasets are used "internal" to the macro and will create an important dataset of the same name as part of the larger program that calls the macro, and then the macro will overwrite or otherwise corrupt that dataset. Currently my only idea is to utilize obscure dataset names within the macro, but that doesn't seem very elegant.

 

Thanks!


Accepted Solutions
Solution
‎09-07-2016 11:19 AM
Super User
Posts: 5,509

Re: avoiding macro conflicts

I haven't heard of any such resources, but here are a few pieces of advice.

 

First, don't think of the data set names as "obscure".  Think of them (and make them) descriptive, and keep in mind that you can use 32 characters to name a data set.  Remember, you only have to type out the names once and the macros will do it from that point forward.

 

Second, consider assigning a short acronym to each macro.  That way, all data set names created by the macro can begin with that acronym.  It makes debugging somewhat easier as well.

 

Finally, remember to set up your sandbox for macro variables (not just data sets).  This means adding %LOCAL statements liberally whenever a macro variable is supposed to be local to that macro.  After all, when %A calls %B, you don't want the running of %B to change the values of macro variables in the symbol table for %A.

View solution in original post


All Replies
Solution
‎09-07-2016 11:19 AM
Super User
Posts: 5,509

Re: avoiding macro conflicts

I haven't heard of any such resources, but here are a few pieces of advice.

 

First, don't think of the data set names as "obscure".  Think of them (and make them) descriptive, and keep in mind that you can use 32 characters to name a data set.  Remember, you only have to type out the names once and the macros will do it from that point forward.

 

Second, consider assigning a short acronym to each macro.  That way, all data set names created by the macro can begin with that acronym.  It makes debugging somewhat easier as well.

 

Finally, remember to set up your sandbox for macro variables (not just data sets).  This means adding %LOCAL statements liberally whenever a macro variable is supposed to be local to that macro.  After all, when %A calls %B, you don't want the running of %B to change the values of macro variables in the symbol table for %A.

New Contributor
Posts: 2

Re: avoiding macro conflicts

Posted in reply to Astounding

Thank you for the quick reply!

 

I think these two techniques will do the trick.

☑ This topic is solved.

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

Discussion stats
  • 2 replies
  • 256 views
  • 1 like
  • 2 in conversation