Date:         Wed, 9 Jun 2010 09:18:57 -0400
Reply-To:     Scott Bass <sas_l_739@YAHOO.COM.AU>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Scott Bass <sas_l_739@YAHOO.COM.AU>
Subject:      Re: Drop a renamed variable using the drop statement

Ok, I'll try to give a better explanation...

Example code:

options mprint;

%macro inner;
   length __v1 __v2 8;
   rename __v1=wanted;
%mend;

%macro wrapper;
   %inner;
   drop __v1 __v2;
%mend;

data test;
   %wrapper;
run;

Say the inner macro is a generic, utility macro.  The easiest solution was
to unconditionally allocate some working variables, say __v1 and __v2.
However, based on the values of some macro parameters, I rename the utility
variables to something more meaningful.  I leave these variables in the data
set for further downstream processing if desired.  Otherwise the user can
drop these variables outside the utility macro.

However, the wrapper (outer) macro calls the inner utility macro, leveraging
its functionality by hardcoding a number of parameters to the inner macro.
In this scenario, I've decided to drop the working variables declared by the
utility macro in the inner macro.

I guess I need to hit the doc again, but I thought the drop statement was a
compile time statement that only took effect when the data set is written.

For example:

data test;
   length x 8;
   drop x;
   x=3;
   y=x*2;
   rename x=a;
   z=x**2;
run;

y & z are still the expected values, even though it was "dropped" before any
reference to the variables.  And the rename statement does not take effect
until the final dataset is written.

Finally, the gory details are that the working variables __v1 and __v2 are
parameters to call is8601_convert.  The data type of the target variables
(date/time/datetime) is dependent on the parameters to call is8601_convert.
 It seemed easiest to just declare generic working variables, then rename
them based on the parameters to is8601_convert.

Perhaps the easiest solution is just to drop the rename in the inner macro...

Scott

On Wed, 9 Jun 2010 14:04:17 +0200, karma <dorjetarap@GOOGLEMAIL.COM> wrote:

>Hi Scott,
>
>The order or execution is drop then rename. In your first example you
>are trying to rename a variable that doesn't exist, and in the second
>example you are trying to drop a variable that doesn't exist (as it
>hasn't been renamed yet).
>
> The only ways I can think of to change this order is on the datastep
>options (i.e renaming on the set statement or dropping on the data
>statement). But why do you want to drop a renamed variable anyway? In
>both examples you have given, removing the drop statement leaves a
>dataset without the foo variable as it is being renamed.
>
>Karma
>
>On 9 June 2010 13:00, Scott Bass <sas_l_739@yahoo.com.au> wrote:
>> Hi,
>>
>> I have a utility macro called by a wrapper macro.  The utility macro creates
>> data step variables that I want to drop in the wrapper macro.
>>
>> Here is simplified code:
>>
>> data test;
>>   length foo 8;
>>   rename foo=bar;
>>   foo=1;
>>   drop foo;
>> run;
>>
>> This results in a warning.  So, trying this:
>>
>> data test;
>>   length foo 8;
>>   rename foo=bar;
>>   foo=1;
>>   drop bar;
>> run;
>>
>> This results in the same warning.
>>
>> Is there a way to drop foo from the final dataset using a drop statement?
>>
>> Thanks,
>> Scott
>>