Date: Thu, 20 May 2004 08:28:07 -0400
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: Scope of Macro Variables
Content-Type: text/plain; charset="US-ASCII"
> From: Curt Seeliger [mailto:Seeliger.Curt@EPAMAIL.EPA.GOV]
> RJF2 writes:
> > > 1. An invocation of a macro may fail the first time and
> > > not on the second invocation. As soon as a global
> > > macro variable is created the program environment changes.
> > why we test in batch
> > the assumption is that a macro allocates a global macro variable I
> > agree, not Good Practice.
> Having not gone up the learning curve and experienced each of
> anyone's four points, I don't agree or I don't understand
> this one point on good housekeeping.
> Allowing macros to declare <---<<<
> the global macro variables they set <---<<<
> hides complexity and groups functionality
> for easier maintenance and improved readability.
ah, sorry, I may be talking to myself in my idiolect.
I use 'allocate' to mean the two steps:
* think up a name , aka 'declare'
* assign a value to, aka 'set'
that (variable) name
I agree that macros may (re)assign a value
to a %global macro variable
I disagree that a macro ought to declare a %global macro variable.
I suggest that the calling program,
should have the task of declaring %global mvars.
and then (%sym)deleting them.
The side effect should be a new value for an already existing mvar
not a new macro variable.
Ron Fehd the macro maven CDC Atlanta GA USA RJF2@cdc.gov
remember perspective: the error is not always where it seems to occur!
... but the allocation should always be visible