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
"call symput"
In-Reply-To: <003701c88e93$5541c710$ffc55530$@com>
Content-Type: text/plain; charset=us-ascii
Alan,
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
table.
John Gerstle
MS Applied Neuroscience, MS Applied Statistics
Biostatistician
Northrop Grumman
CDC Information Technological Support Contract (CITS)
NCHSTP \DHAP \HICSB \Research and Dissemination Team
Centers for Disease Control and Prevention
Phone: 404-639-3980
Fax: 404-639-2980
yzg9 at cdc dot gov
>>-----Original Message-----
>>From: owner-sas-l@listserv.uga.edu
[mailto:owner-sas-l@listserv.uga.edu]
>>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
using
>>"call symput"
>>
>>I would amend your "table-driven programming" to "metadata driven
>>programming".
>>
>>I have built UIs that were completely driven by SQL Server tables and
SAS
>>datasets (buttons, tabs, tree structures, etc. were dynamic and
changed
>>according to what was in the table). I also do a lot of work using XML
>>which
>>is hierarchical and much better suited to a lot of tasks. XML is also
much
>>more flexible than row/columns and is increasingly used vs.
table-driven.
>>
>>Alan
>>
>>Alan Churchill
>>Savian
>>www.savian.net
>>
>>
>>-----Original Message-----
>>From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Mary
>>Sent: Tuesday, March 25, 2008 8:28 AM
>>To: SAS-L@LISTSERV.UGA.EDU
>>Subject: Table-driven programming WAS: Scope of macro variable using
"call
>>symput"
>>
>>Actually, I do find what data_null is saying here to be very wise
advice,
>>and actually in the direction that software engineering has taken a
hold
>>of
>>lately, the concept of "table-driven programming".
>>
>>In working at the hospital, we saw that the large companies involved
in
>>producing medical records software (IDX, EPIC), very much used the
concept
>>of "table-driven programming" in their designs, in that database
tables
>>could be used to a great extent over using individual variables or
hard
>>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
>>could
>>change.
>>
>>This made a lot of sense to me, since I had been a statistical
programmer.
>>SAS is a natural language to implement this idea, since it focuses
around
>>the data set. It did strike me as a bit odd when I first joined the
list
>>as
>>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
by
>>passing parameters, but not as a substitute for SAS's rich data step
>>language (but then, I'm a statistical programmer and my SAS
applications
>>may
>>be different than that of a non-statistical SAS programmer).
>>
>>Thus, data_null's idea of relying on data steps, and using data sets
where
>>possible rather than macro variables, makes a lot of sense to me, and
>>actually seems to be more consistent with the "table-driven"
programming
>>concepts that seem to be taking hold in the software industry.
>>
>>
>>-Mary
>> ----- 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
set
>> into macro variables
>>
>> I don't have a web page with examples of macros like you have. Nor
do
>> I have web page of the kind of programs that I do write. There are
a
>> few examples on SAS-L of the kinds of programs write. I like to
write
>> stand alone (self contained) programs that use data and proc steps
to
>> 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
step
>> language or procs to drive the application. Sure you may need or
want
>> 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
from
>> the data set into macro variables what did you do next? Could any
or
>> all of that been done more easily using data step language?
>>
>> >
| 
