| Date: | Thu, 14 Jan 1999 14:50:27 -0500 |
|---|
| Reply-To: | "Self, Karsten" <Karsten.Self@SCHWAB.COM> |
|---|
| Sender: | "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU> |
|---|
| From: | "Self, Karsten" <Karsten.Self@SCHWAB.COM> |
|---|
| Subject: | Re: Scoping variables one level up |
|---|
|
| Content-Type: | text/plain |
|---|
I solved this in one instance by creating a data step view within the called
macro, which was then executed in the calling macro. The macrovariables
created as a result (via CALL SYMPUT) are then scoped to the calling macro.
E.g.:
%macro calling;
/* stuff */
%called;
data _null_;
set mvargen;
run;
run;
%macro called;
data mvargen /view= mvargen;
call symput('foo', put(_n_, best.));
run;
%mend;
%calling;
--
Karsten M. Self (Karsten.Self@schwab.com)
Trilogy Consulting
What part of "gestalt" don't you understand?
WARNING: All e-mail sent to or from this address will be received by the
Charles Schwab corporate e-mail system and is subject to archival and
review by someone other than the recipient.
This communication does not necessarily reflect the views or position of The
Charles Schwab Corporation, or any of its subsidiaries or their affiliates.
> ----------
> From: David D Kane[SMTP:ddk@NUMERIC.COM]
> Reply To: David D Kane
> Sent: Thursday, January 14, 1999 7:28 AM
> To: SAS-L@UGA.CC.UGA.EDU
> Subject: Scoping variables one level up
>
> <<File: vcard.vcf>>
> Surely, someone has already solved this problem.
>
> How does one force a macro variable to have a scope that is one level
> above the macro in which it is created but *not* global?
>
> Consider a utility (attached at the end of this message) that creates an
> inderminate number of macro variables (var1, var2, etc) on the basis of
> the observations in a data set. I use this utility (ScanList) all the
> time (if someone has a better version, please post it). In order for the
> calling macro to uses var1, var2 . . ., I need to declare them as
> global.
>
> The problem is that I work on big projects with other people. These
> projects might have a large macro, call it top, which would call my
> macro, call it middle1, which uses ScanList as well as Jones' macro,
> call it middle2, which also calls ScanList. But Jones and I may not know
> about each other and now the global variables (which we really want to
> be *local* to middle1 and middle2) can conflict with each other in top.
> This is a problem. How should we solve it? How do we "transfer" a macro
> variable created in ScanList to the calling macro without making that
> macro variable global?
>
|
