Date: Tue, 25 Mar 2008 12:40:09 -0400
Reply-To: "Gerstle, John (CDC/CCID/NCHHSTP) (CTR)" <yzg9@CDC.GOV>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Gerstle, John (CDC/CCID/NCHHSTP) (CTR)" <yzg9@CDC.GOV>
Subject: Re: Table-driven programming WAS: Scope of macro variable using
Content-Type: text/plain; charset=us-ascii
I've seen this mentioned many times on the list, by you mostly I think.
And I'm curious.
What reference material do you recommend for one to get up to speed on
using XML driven process (papers, etc).
I've used tagsets to create XML files and have tried fixing issues by
opening the XML file, but, as a very visual person, I find it difficult
to understand the XML structure without looking at it and seeing a
MS Applied Neuroscience, MS Applied Statistics
CDC Information Technological Support Contract (CITS)
NCHSTP \DHAP \HICSB \Research and Dissemination Team
Centers for Disease Control and Prevention
yzg9 at cdc dot gov
>>On Behalf Of Alan Churchill
>>Sent: Tuesday, March 25, 2008 12:15 PM
>>To: 'Mary'; SAS-L@listserv.uga.edu
>>Subject: RE: Table-driven programming WAS: Scope of macro variable
>>I would amend your "table-driven programming" to "metadata driven
>>I have built UIs that were completely driven by SQL Server tables and
>>datasets (buttons, tabs, tree structures, etc. were dynamic and
>>according to what was in the table). I also do a lot of work using XML
>>is hierarchical and much better suited to a lot of tasks. XML is also
>>more flexible than row/columns and is increasingly used vs.
>>From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
>>Sent: Tuesday, March 25, 2008 8:28 AM
>>Subject: Table-driven programming WAS: Scope of macro variable using
>>Actually, I do find what data_null is saying here to be very wise
>>and actually in the direction that software engineering has taken a
>>lately, the concept of "table-driven programming".
>>In working at the hospital, we saw that the large companies involved
>>producing medical records software (IDX, EPIC), very much used the
>>of "table-driven programming" in their designs, in that database
>>could be used to a great extent over using individual variables or
>>coding of data, and thus the code would not have to be tailored for a
>>different client but rather the contents of the tables for each client
>>This made a lot of sense to me, since I had been a statistical
>>SAS is a natural language to implement this idea, since it focuses
>>the data set. It did strike me as a bit odd when I first joined the
>>to how much was being done in macros that could have been done in data
>>steps; to me, macros were primarily useful in reducing repetitive code
>>passing parameters, but not as a substitute for SAS's rich data step
>>language (but then, I'm a statistical programmer and my SAS
>>be different than that of a non-statistical SAS programmer).
>>Thus, data_null's idea of relying on data steps, and using data sets
>>possible rather than macro variables, makes a lot of sense to me, and
>>actually seems to be more consistent with the "table-driven"
>>concepts that seem to be taking hold in the software industry.
>> ----- Original Message -----
>> From: data _null_,
>> To: SAS-L@LISTSERV.UGA.EDU
>> Sent: Monday, March 24, 2008 6:40 PM
>> Subject: Re: Scope of macro variable using "call symput"
>> I don't claim to know anything I am a student of SAS programming. I
>> still say that it is pointless to process all variables in a data
>> into macro variables
>> I don't have a web page with examples of macros like you have. Nor
>> I have web page of the kind of programs that I do write. There are
>> few examples on SAS-L of the kinds of programs write. I like to
>> stand alone (self contained) programs that use data and proc steps
>> accomplish tasks. For some time I had tried to use the approach you
>> seem to prefer where every little task is canned into a macro but I
>> found it too burdensome to keep track of it all. Instead of writing
>> more macros I decide to try to learn to write better SAS programs,
>> using traditional SAS code, and macro language where appropriate.
>> It seems that for many programmers they are using macros in a grand
>> battle to tame SAS and have it succumb to their will. I used to be
>> one of them. But if you take a different approach and let SAS help
>> you then most things that seem difficult become much easier.
>> I can't answer that. I read almost everything that is posted to
>> SAS-L. I find it all fascinating.
>> It still seems to me that given a data set as you describe for the
>> purpose you suggest you could do a lot better sticking with data
>> language or procs to drive the application. Sure you may need or
>> to make some macro variables but if you keep the data in a data set
>> longer you are able to make processing them much easier. To better
>> understand your application I ask. Once you put all the variables
>> the data set into macro variables what did you do next? Could any
>> all of that been done more easily using data step language?