Paul,

I would sure agree with you if extracting metadata or some other info into: a host macro variable were the only way where this information can be stored. That oftentimes, storing it in such a macro variable for the future use is the most convenient and straightforward way, I concur; however, it is not the only way. You can select the same info into a SAS file or view and then reference it in the code writing a temp file or running Call Execute.

Kind regards, ---------------- Paul M. Dorfman Jacksonville, FL ----------------

> -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On > Behalf Of Choate, Paul@DDS > Sent: Monday, June 14, 2004 3:32 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: Macro [ab]usage (was: (OT) old style macro is > still working) > > Don't forget the elegant macro-based access to the dictionary > meta-data with SQL Select Into - functionality only > accessible via SAS Macro. > > Paul Choate > DDS Data Extraction > (916) 654-2160 > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On > Behalf Of Paul M. > Dorfman > Sent: Monday, June 14, 2004 10:52 AM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: Macro [ab]usage (was: (OT) old style macro is > still working) > > Quentin McMullen, in part wrote: > > > So to rename a group of variables, I can code: > > > > data b; > > set a (rename=(%rename(x y z,prefix=_))); run; > > > > Now in that sort of situation, I believe %include could not > work, it > > doesn't seem happy in the middle of a statement, e.g.: > > > > data b; > > set a (rename=(%include "c:\junk\renamelist.sas")); run; > > Quentin, > > You are correct, the rules of %include require that its > source must contain complete SAS statements. However, nothing > prohibits one to generate the entire SET statement complete > with the semicolon with the needed variables duly renamed, > which is what is usually done when this technique is used. It > has its unwritten rules (those may be somewhat personal) > designed to make the code being generated eminent enough to > be distinguished from the generating Data step code. I agree, > though, that the macro language makes the distinction more > starkly apparent, partially because its syntax is different. > And I also agree that in the case above, the macro is right > in its place: PUT/include would have to generate the whole > statement, and Call Execute's purpose would be much more > difficult to comprehend. If there are cases (as I believe) > when a macro is more self-explanatory about the purpose of > the action than the code it generates, this is one of the cases. > > Kind regards, > ---------------- > Paul M. Dorfman > Jacksonville, FL > ---------------- >