Date: Thu, 18 Nov 2004 00:05:38 -0800
Reply-To: RolandRB <rolandberry@HOTMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: RolandRB <rolandberry@HOTMAIL.COM>
Subject: Re: proc report in an external macro
Content-Type: text/plain; charset=ISO-8859-1
kevin.auslander@SBCGLOBAL.NET (Kevin Auslander) wrote in message news:<firstname.lastname@example.org>...
> Roland, thanks for your input and to all the others who wrote me. I am aware that parameters can be defaulted to specific values. I am also aware of the concept of using a validated macro vs using a proc in open code. The outputs we are creating do not all have common variable names, lengths, types. Therefore, I still don't think proc report should go in an external macro.
> Although many parameters like spacing, linsize, and page size can be
set to defaults, many other parameters will have to be specified every
time. Variable names, column labels, column widths, which columns are
order columns, which columns require the flow option, which columns
are noprint etc. Macro quoting functions will need to be used for
some of the parameters that may have special characters such as column
> Then consider the time it takes to develop, debug and implement such a macro. All the programmers need to learn how to use it. When a programmer encounters errors it will take them longer to debug it because the macro call adds a level of complexity.
> On the subject of validation, Proc Report has already been thoroughly validated by the SAS institute. It is simple and straightforward in that it reports the values of the variables that the programmer supplies to it. It would be just as easy, if not more so, for a programmer to misuse a macro which calls proc report, than to misuse proc report directly.
> The small amount, if there is any amount at all, of reliability gained by putting proc report in an external macro is not worth the extra time it takes to develop and implement such a macro.
Then don't use a macro.