Date: Thu, 12 Dec 2002 10:12:09 -0500
Reply-To: "Fehd, Ronald J. (PHPPO)" <rjf2@CDC.GOV>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Fehd, Ronald J. (PHPPO)" <rjf2@CDC.GOV>
Subject: Re: recruiting cheesy, sleasy SAS tricks tip call execute
Content-Type: text/plain
> From: Ian Whitlock [mailto:WHITLOI1@WESTAT.com]
> You say:
> > NOTE: call execute will not work correctly,
> > i.e., as you expect,
> > when you pass a complex macro call to it.
> > a macro with complexity is one that has symput,
> > or macro control statements: %IF or %DO, etc.
Ian, I'll sit with my statements above,
and add the note-to-self below. thank you.
> %macro q ;
> data q ;
> x = "HELLO from dataset Q" ;
> run ;
> title "Print of Dataset &syslast" ;
> %mend q ;
I'm surprised that you would illustrate things going wrong
with this example.
item#1
RUN; %mend q ;
if we're discussing step boundaries,
let's not muddy the waters any more than they have to be.
i.e., a macro which returns a procedure
I suggest Good Practice would be a set of -complete- steps.
> data w ; x = 1 ; run ;
> data _null_ ;
> call execute ( '%q' ) ;
and did you test my recommended:
call execute ( '%nrstr(%q' ) ;
?
> run ;
*call execute is executed in this step;
> proc print data = q ;
> run ;
>
>
> Note the macro has only one step and one global statement.
> No macro instructions are used with the exception of the
> reference to one system provided macro variable. However,
> the title on the subsequent print will be incorrect because
> the principle given above was violated.
Point taken, and well made.
Note to Self, 'macro complexity'
includes the use of system macro variables
changed between steps.
> I consider the use of %NRSTR to postpone the execution of the
> macro until after the executing DATA step far too important
> to be included in any list of sleazy tricks. I even resent
> calling it a trick. In fact I wish SI would add a new
> routine CALL NREXECUTE to facilitate this type of code. If
> there is any sleaze in CALL EXECUTE, it lies in the lack of
> programmer control over the log.
uh, that wasn't the point of my sleazy
-- actually it was pretty sophisticated, come to think of it --
trick.
the point was swapping the output from file PRINT for review
to execution
with a macro variable CMD
%nrstr helped assure that what I saw was what I'd get
Ron Fehd the macro maven CDC Atlanta GA USA RJF2@cdc.gov
do not fold, spindle, or mutilate -- IBM punch card
... the call execute argument(s)
