topic Re: Resolving macro variable creating data-step read error in SAS Programming

Resolving macro variable creating data-step read error

hellind — Fri, 29 Apr 2022 13:36:08 GMT

data _null_;
call symput('yymmp',PUT(intnx('Month',"&SYSDATE"d,-2,'Ending'),yymmn4.));
run;
%put &=yymmp;

data _time_;
lrpt_dte = intnx('MONTH', "&SYSDATE"d, -2, 'B');
lrpt_yyyymmdd = input(put(lrpt_dte,yymmddn8.),$8.); *20180228;	
yymmp = substr(lrpt_yyyymmdd,3,4);
call symput('yymmp',yymmp);
run;
%put &=yymmp;

data  v_rskp;
set gcbc.eop_&yymmp._drv_rskp; 
run;

I have two ways off creating the macro variable &YYMMP.

And both according to logs return 2202

May I know why the data-step return error when I use the 2nd way of assigning &YYMMP.

Why isn't it resolving to

gcbc.eop_2202_drv_rskp

LOGS:

21         
22         data _null_;
23         call symput('yymmp',PUT(intnx('Month',"&SYSDATE"d,-2,'Ending'),yymmn4.));
24         run;

NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds
      

25         %put &=yymmp;
YYMMP=2202
26         
27         data _time_;
28         lrpt_dte = intnx('MONTH', "&SYSDATE"d, -2, 'B');
29         lrpt_yyyymmdd = input(put(lrpt_dte,yymmddn8.),$8.); *20180228;	
30         yymmp = substr(lrpt_yyyymmdd,3,4);
31         call symput('yymmp',yymmp);
32         run;

NOTE: Compression was disabled for data set WORK._TIME_ because compression overhead would increase the size of the data set.
NOTE: The data set WORK._TIME_ has 1 observations and 3 variables.
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds
      

33         %put &=yymmp;
YYMMP=2202
34         
35         data  v_rskp;
36         set gcbc.eop_&yymmp._drv_rskp;
ERROR: File GCBC.EOP_2202.DATA does not exist.
37         run;

It is able to resolve to correct dataset name when I use the first way of assigning the macro variable.

Thanks.

Re: Resolving macro variable creating data-step read error

AMSAS — Fri, 29 Apr 2022 13:57:11 GMT

Add TRIM to your call symput:

call symput('yymmp'trim(,yymmp));

I ran a simple test, and got a slightly different error to you, but it gave me enough of a hint in the ERROR: messages

94  data _time_;
395  lrpt_dte = intnx('MONTH', "&SYSDATE"d, -2, 'B');
SYMBOLGEN:  Macro variable SYSDATE resolves to 29APR22
396  lrpt_yyyymmdd = input(put(lrpt_dte,yymmddn8.),$8.); *20180228;
397  yymmp = substr(lrpt_yyyymmdd,3,4);
398  call symput('yymmp',yymmp);
399  ll=length(yymmp) ;
400  put _all_ ;
401
402  run;

lrpt_dte=22677 lrpt_yyyymmdd=20220201 yymmp=2202 ll=4 _ERROR_=0 _N_=1
NOTE: The data set WORK._TIME_ has 1 observations and 4 variables.
NOTE: DATA statement used (Total process time):
      real time           0.01 seconds
      cpu time            0.01 seconds


403
404  options symbolgen ;
405
406  data test ;
SYMBOLGEN:  Macro variable YYMMP resolves to 2202
407      set eop_&yymmp._drv_rskp ;
ERROR: File WORK.EOP_2202.DATA does not exist.
ERROR: File WORK._DRV_RSKP.DATA does not exist.
408  run ;

Re: Resolving macro variable creating data-step read error

Tom — Fri, 29 Apr 2022 14:12:26 GMT

For most purposes just use the normal (no longer NEW by any definition of that word) CALL SYMPUTX() function instead.

call symputX('yymmp',yymmp);

You should really only use the OLD (very very old) CALL SYMPUT() function if you have some special need to store leading and/or trailing spaces into the macro variable.

Another possible issue to watch out for is parsing issues. Sometimes in macro code building a single SAS token from macro code confuses the SAS parser and it sees the value as two token, even though there isn't really any space there. You can use %UNQUOTE() to fix that.

set %unquote(gcbc.eop_&yymmp._drv_rskp);

Or what I find easier to understand is to just build the value into another macro variable and use that.

%let dsname=gcbc.eop_&yymmp._drv_rskp;
set &dsname.;

But you should not see that in the open code example you posted.

Re: Resolving macro variable creating data-step read error

Kurt_Bremser — Fri, 29 Apr 2022 14:18:48 GMT

You did not set a length for the variable yymmp, so it "inherits" the length from lrpt_yymmdd,, and has trailing blanks. Using CALL SYMPUTX instead of CALL SYMPUT works around this (SYMPUTX strips leading and trailing blanks, like a %LET).