Please see embedded comments.
Date: Sat, 2 Sep 2006 18:25:40 -0400
Reply-To: Arthur Tabachneck <art297@NETSCAPE.NET>
Sender: "SAS(r) Discussion"
From: Arthur Tabachneck <art297@NETSCAPE.NET>
Subject: Re: Macro vs user
Comments: To: Ian Whitlock <iw1junk@COMCAST.NET>
First, thanks for the link to Marriot reservations. The following is a
link to my previous post which I think contains all three of the original
***Thanks for the correction, I have no idea what went wrong with the
I'm not going to defend the right of "users" to make use of SAS macros as,
on this one occasion, I don't believe you've made a sufficient argument.
***You appear to contradict yourself below.
You also misrepresented Toby's example which was actually:
%Macro PrintIt( DataIn = ) ;
Data =&DataIn ;
%Mend PrintIt ;
The fact that it required 34 extra keystrokes to code isn't the
significant part but, rather, that it also requires the file name to be
entered correctly every time it is run.
If, as a user I often print the file I've just worked on, it is much
easier, quicker and less prone to errors for me to enter %print than it is
to enter an alternative (other than an abbreviation for the above like the
letter "P"). It also not prone to having the user enter an incorrect but
valid filename and incorrectly think they are reviewing the correct data.
*** Toby's example did start with the code I quoted. I agree with Toby
about the need for a parameter and didn't see any need to mention his
improvement, since I thought it too simple to show his point.
When I mentioned key strokes I was taking that from your message (see
your corrected address) with the comment after your macro stating that
the macro saved valuable key strokes. The macro was
>AT> %macro Print; >AT> Proc Print; >AT> Run ; >AT> %mend;
In letters it cost the length of %PRINT and what was saved was
proc print ; run ;
If I am working in a mode where I need to see each data set and that is
enough of a check, I use the View Table with a click, saving still more
keystrokes and the ability, for example, to reach the 70th variable on
observation 15,000 without waging though many pages of a print. So I am
completely missing the value of your macro. However, if you find it
valuable, you should consider making the code a keyboard macro to save
even more keystrokes.
But then I think of asking for a print without qualifying the data set
as working in play mode. In 25 years of working in SAS I do not
remember a single mistake where there was confusion because of a wrongly
written data set name, although I have misspelled the names on some
occasions. On the other hand I do remember helping students and
colleagues who came to me after getting into trouble by failing to
qualify the data set name. Consequently it has been my experience that
leaving out data set names is the bigger danger. In fact, one of the
very first habits I developed when I started using SAS was to always use
the DATA= parameter.
I don't at all question your comments regarding the uselessness of
programs that don't correctly accomplish that for which they were
intended, but I have seen many programs written by supposedly
qualified "programmers" that don't meet that criterion.
*** Unfortunately you are correct that programmers also make mistakes.
One of the biggest is the ubiquitous belief among programmers, "I cannot
make a mistake."
Whenever I've had a "big" programming project, yes, I've contracted
qualified SAS professional programmers. However, since they typically are
not experts in the particular subject matter involved, I've found it most
useful to provide them with a working, tested set of code that does what I
need and asked them to restructure the code to ensure that it always
provides valid results, in the shortest time, using the least possible
resources and, hopefully, eliminating as much of the potential user error
However, that said, does one have to pass a particular test or attain a
particular distinction before they will be "allowed" to use SAS macros? I
don't believe that the SAS license contains any such requirement.
***No they do not. In fact, SI often provides the means to do unwise
From a business perspective, of course, valid results without overusing
the company's or organization's resources is critical. But that is up to
the individual (user or programmer), company or organization to ensure,
not SAS and definitely not SAS-L.
I have never viewed SAS-L as controlling any company or organization in
any way including the use of SAS. I do think of SAS-L as a place where
individuals do and should express there opinions on best methods of
coding SAS. So I would never attack your right to express the value of
proc print ; run ;
and a macro to save some of these keystrokes, however, I do not think
that opinion should be left unquestioned.
My point? If one can "use" or "program" SAS to correctly and defensibly
accomplish what they need, within the time and resources they are allotted,
then it is simply wrong to tell them that they are unqualified or that
they can't take advantage of all of the SAS capabilities unless they make
their code more complex to meet particular "programming principles" is
simply not justified.
I am not saying that you are unqualified in any way. But I am saying
that some of your practices can be dangerous to others. In particular,
I am saying that *in general* macros written by people with little SAS
programming experience tend to waste time and breed mistakes both in the
intended project and the programming development of the macro's author.
*In general* means that I think each person should think carefully about
any proclaimed advantage to writing macros before they have sufficient
programming experience and consider all arguments against. That does
not mean that you or anyone else has to follow any idea that I have
expressed. In fact, you are at the end of a long line of people who do
not take my advice. Some were happy, some were not, and most were not
awake enough to know that they had made a choice.
On Sat, 2 Sep 2006 20:04:52 +0000, Ian Whitlock <iw1junk@COMCAST.NET>
>Subject: Macro vs user
>Originally: Re: OT: RE: Select column names based on the column values
>Summary: The case against user written macros
>Respondent: Ian Whitlock
>An interesting question arose from the original topic because Toby Dunn
>emphasized a non-macro solution. For a message containing what is
>sumarized here, see http://tinyurl.com/gxp5
>Jack Clark asked, what was wrong with macros without parameters,
>latter saying that he used them all the time because they let him
>use macro instructions.
>Toby replied mentioning design flaws in macro design, probably
>because he liked the sound of the words and has recently written a
>NESUG paper on the subject. He then offered a macro having
>little to do with anything except for the fact that it had no
>TD> %Macro PrintIt ;
>TD> Proc Print
>TD> Data = XYZ ;
>TD> Run ;
>TD> %Mend PrintIt ;
>Arthur Tabachneck responded with a simplification claiming it to be more
>useful saving (11) key strokes
>AT> %macro Print;
>AT> Proc Print;
>AT> Run ;
>and justified this work on the basis that **users** need to save time
>and thus programming principles should not apply. That is the
>question and one he has raised before in less stark terms.
>In this case, I think the saving in time is very questionable. How much
>time is spent remembering to use the macro? How much time is spent when
>without titles one get's confused at what data set is reported? How much
>time is spent when applied to real sizable data sets? How much time is
>spent when someone else has to run the program and it fails for lack of
>autocall library? Moreover, I suspect that all these prints may lead one
>to think the work is adequately checked. Then how much time is lost when
>the program contains a mistake?
>In a big project somebody thinking about saving a few key strokes is down
>right dangerous. I already question the validity of any sizable project
>developed by **users**, but to add that they should write and use macro
>code makes the validity of the result so much more questionable.
>Now let's look at Jack's question in terms of the macro solution he
>presented to the original question. "In this I want to select all the
>column names having minimum value of -100. can I use sashelp.vcolumn."
>JC> data test;
>JC> input col1 col2 col3;
>JC> 23 40 30
>JC> -100 30 40
>JC> 25 -100 35
>JC> proc sql noprint;
>JC> select count(*),name
>JC> into :vcnt, :vnames separated by ' '
>JC> from dictionary.columns
>JC> where libname='WORK' and memname='TEST'
>JC> %put &vcnt;
>JC> %put &vnames;
>JC> %macro chkmin;
>JC> %do i = 1 %to &vcnt;
>JC> proc sql;
>JC> %if &i = 1 %then %do;
>JC> create table keepcols
>JC> (col_name char(20));
>JC> insert into keepcols
>JC> select "%scan(&vnames,&i)" as col_name
>JC> from test
>JC> where %scan(&vnames,&i) <= -100
>JC> proc print data = keepcols;
>JC> %mend chkmin;
>First of all, it tests for columns with values less than or equal to -100
>rather than for columns with a minimum of -100. Of course, this may have
>been what was wanted or it may not matter. Then it sends the column name
>to the table KEEPCOLS each time the condition is met. Consequently there
>can be many unwanted duplicates. It is rather inefficient because it
>SQL and does a separate SQL statement (data pass) for each column. Say
>there are 100,000 observation and 100 columns, that is ten million
>observations to process. Since Art has placed the emphasis for using
>on time, this may be the most important reason for not using macros unless
>developed by programmers worthy of the distinction between user and
>There is no reason why, the SQL step before the macro, should not be
>the macro. In a complex system it would be important to make the macro a
>complete package without polluting the global name space.
>I think there are several reasons why it is questionable whether
>as opposed to programmers, should be writing macros to save time:
> 1) Concentration on simple SAS helps produce reliability
> 2) Concentration on macro means missing the opportunity for many better
> solutions - stunting growth
> 3) Concentration on macro writing without adequate testing techniques
> reduces reliability
>The only saving grace is that users tend to write small simple programs
>where the costs may not matter to anyone but the user, unless other people
>depend on the results and their being efficiently obtained. I suspect
>users never recognize the costs in terms of time and reliability of
>one use code in throw away macros.