Date:         Mon, 6 Oct 1997 17:19:43 GMT
Reply-To:     Jon Seltzer <seltzerjd@PHIBRED.COM>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Jon Seltzer <seltzerjd@PHIBRED.COM>
Organization: Pioneer Hi-Bred International, Inc.
Subject:      Re: Abusing SAS Macros

Correction: Actually after counting I found only eight messages from
SAS-L that were not posted in the news group.
eltzerjd@PHIBRED.COM (Jon Seltzer) wrote:
 
>Making Gross generalizations and being correct most of the time is
>what I get paid for!  The reason why this thread has generated so much
>controvery is because there are a large number of SAS programmers that
>have been seriously hosed by the code generated from novice
>programmers, or Data based programmers comming into SAS that have
>abused the Macro and SQL language.  Ultimately this abuse results in
>hundreds of thousands or millions of dollars lost for the people that
>employe SAS programmers, and severe frustration for the programmers
>hired to clean up other peoples programming messes.   I did not
>recieve your message on SAS-L.  I found your message on the news
>group.  There are about 20 or so messages on SAS-L that are not posted
>in this news group.  Many of these messages provide concrete examples
>of Macro and SQL abuse including one of mine.  Ultimately if Macro
>Abuse and SQL abuse did not result in a large amount of money being
>lost no one would care.  The fact is Macro and SQL abuse is a
>significant problem where many of the culprets that do it, do not
>care. Ultimately their actions will reflect negatively on SAS
>programmers as a whole, increasing the probablity that a company may
>switch to other statistical packages or not choose SAS from the start!
>Don Stanley <don_stanley@ibm.net> wrote:
 
>>How about calling a halt to this thread. All its doing for me now is
>>helping generate a list of people I don't ever want to employ. Its
>>absurd to argue against using features of a product just because you
>>don't like them which is how this trend is going, there's little data
>>being put forward to substantiate these comments like below -- for
>>instance I didn't see Roger state anywhere below that his client had no
>>advanced SAS expertise to look after these macros, hes been attacked
>>just for using them. I suspect that his approach is like most
>>consultants -- get the best thing for the client within the constraints
>>imposed by the clients -- which may mean changing the appraoch to the
>>same problem for different clients.
 
>>SQL, macro, data step are all incredibly important to SAS and those of
>>us who use SAS in a software development role combining data from many
>>sources taking advantage of macro code to trigger code that changes
>>according to events that may have occurred are constantly thanking The
>>Great Ones at Cary for the sheer flexibility and power of SAS. Otherwise
>>we'd all be using something like C++ and DBMS database SQL. Or worse
>>Microsoft Access. Which incidentally generates SQL through those pretty
>>front end query windows. SQL? now why would we want that!
 
>>Bah, I thought I was bad getting people wound up about viewtable! Macros
>>have been around since release 82.4. The original poster had some valid
>>points which mostly come down to beginners getting carried away in my
>>experience. But they are an integral part of the base product and SQL is
>>just SAS remaining commercially viable by supporting an industry
>>standard tool. Its a good SQL, its like any tool, don't use it if you
>>don't understand it. And don't make gross generalisations about the
>>motives and skills of people who do.
 
>>Don
 
 
>>Seltzer, Jon D. wrote:
>>>
>>> What you are doing as a consultant is making the company you are working
>>> for completely dependent on you: Guaranteed Employment.  From your
>>> perspective: a meal ticket is a meal ticket is a meal ticket.  The party
>>> is going to start when you are gone(If ever!), and they need to modify
>>> your abundant macro code for subsequent analyses.  With the volume of
>>> macro code you are suggesting you are writing, I suspect documentation
>>> will not be enough do prevent substantial down time and money lost as
>>> another SAS programmer is hired to figure out what you did.  The worst
>>> case scenario after you leave (If ever) is all your work is scrapped
>>> because as time progresses it becomes outdated, and it will take too
>>> long to figure out and modify. Even in this scenario you end up
>>> providing more work for SAS programmers which benefits us all.  Thank
>>> you!
>>> Seltzers Monthly predictions:
>>> Yes: Some of the time.
>>>
>>> Seltzers profound mathematical conclusion of the month:
>>> If you say the words 'New' 'Miracle' real fast your saying the word
>>> 'Numerical'!!!!!  Wow!
>>>
>>> >----------
>>> >From:  Xlr82sas[SMTP:xlr82sas@AOL.COM]
>>> >Sent:  Thursday, October 02, 1997 11:38 PM
>>> >To:    SAS-L@VM.MARIST.EDU
>>> >Subject:       Re: Abusing SAS Macros
>>> >
>>> >As a consultant, I use the macro language heavily to generate code. I
>>> >sometimes
>>> > use the noreservedb and mprint option to 'compile' the macro and give the
>>> > client '%' and '&' free code. You do need a reasonable code formatter to
>>> > structure the mprint code.
>>> >
>>> >Generally it is good idea to declare most externals as macro variables.
>>> > Externals are Inputs, Process ( hardcoded conditions ) and Outputs. As
you
>>> >try
>>> > to put your objects ( macros ) together you may come to the realization
that
>>> > other key variables need to be macro variables, ie program names,
>>> >dependencies
>>> > and error codes.
>>> >
>>> >One one job, I was able to convice data managers to build macro shells.
These
>>> > shells would contain macro keyword arguments with all externals and
process
>>> > variables defined. All I had to do was put the code between the macro and
>>> >the
>>> > mend.  The shell would even update a metatable with the inputs, process
and
>>> > outputs. Both the macro and a front end could update the metadata. If the
>>> > keyword argument umeta was set to yes then the macro keyword arguments
would
>>> > be overwritten by the meta-table. It was a nice table driven methodology.
>>> >The implementation was simple, mainly because of the new '%syscall set'
>>> > function.
>>> >
>>> >
>>> >
>>> >
>>> >Roger J DeAngelis
>>> >CompuCraft Inc
>>> >XLR82SAS@aol.com ( Accelerate to SAS )
>>> >http://members.aol.com/xlr82sas/utl.html
>>> >
 
>>--
>>------------------------------------------------
>>Don Stanley
>>Senior Consultant and Director
>>Sysware Consulting Group
>>Email: don_stanley@ibm.net
 
>>Author:       Beyond The Obvious With SAS Screen Control Language
 
>>Box 14554, Kilbirnie, Wellington, NEW ZEALAND