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
Comments: cc: Seeliger.Curt@EPAMAIL.EPA.GOV
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!
-- RJF2

... but the allocation should always be visible