topic Re: Macro variable resolution in Advanced Programming

Macro variable resolution

PeterClemmensen — Wed, 11 Nov 2020 10:37:54 GMT

Hi all.

Can someone help me understand and resolve this problem?

data have;
   do x = 1 to 10000;
      output;
   end;
run;

proc sql noprint;
   select x into :x1 -
   from have;
   %let t = &sqlobs.;
quit;

%put &x1.;
%put &x10000.;

%macro m;
   %do i=1 %to &t.;
      &&x&i
   %end;
%mend;

%put %m;

This gives me quite a lot of the error message below.

"ERROR: The text expression length (65545) exceeds maximum length (65534). The text expression has
been truncated to 65534 characters."

Why does this happen? Works fine with less macro variables?

This is purely for my own understanding, I am well aware that one should not create this many macro variables (as I'm sure @Kurt_Bremser will remind me 🙂 )

Thank you in advance.

Re: Macro variable resolution

PaigeMiller — Wed, 11 Nov 2020 11:07:57 GMT

It's a function style macro, it returns a string that is too long ...

Re: Macro variable resolution

PeterClemmensen — Wed, 11 Nov 2020 11:10:42 GMT

Ok, so this is not because the individual macro variables are two long?

How would I resolve this problem?

Re: Macro variable resolution

Kurt_Bremser — Wed, 11 Nov 2020 11:38:33 GMT

It is not a problem of the macro, it is a problem of %PUT:

data have;
   do x = 1 to 10000;
      output;
   end;
run;

proc sql noprint;
   select x into :x1 -
   from have;
   %let t = &sqlobs.;
quit;

%put &x1.;
%put &x10000.;

%macro m;
   %do i=1 %to &t.;
      x&&x&i. = 0;
   %end;
%mend;

data test;
%m
run;

Runs without problems and creates a dataset with 10000 variables.

Re: Macro variable resolution

PaigeMiller — Wed, 11 Nov 2020 11:39:58 GMT

@PeterClemmensen wrote:

Ok, so this is not because the individual macro variables are two long?

How would I resolve this problem?

What resolution do you want?

Re: Macro variable resolution

gamotte — Wed, 11 Nov 2020 11:54:19 GMT

Hello,

The %put instruction will not accept a string that is more than 65534 characters long

whether is is generated by a macro, macrovariables or typed on the keyboard.

If by "resolving the problem" you mean displaying a longer string in the log you can

use the '@' character in a data step put statements :

data _NULL_;
do i=1 to 70000;
put '1'@;
end;
run;

Re: Macro variable resolution

Astounding — Wed, 11 Nov 2020 12:40:02 GMT

The problem originates within PROC SQL. It is creating individual macro variables that are longer than you expect. You can easily see this by running:

%put *&x1*;

Since macro variables contain text strings, and all the X values are numeric, this statement forces SQL to perform numeric to character conversions:

   select x into :x1 -
   from have;

Unlike a DATA step, SQL doesn't issue a note in the log about the conversions. To alleviate the problem, you can try:

   select strip(put(x,best8.)) into :x1 -
   from have;

Of course the size limit for macro variables still exists. But you don't have to be hitting it with only 10000 integers.

Re: Macro variable resolution

FreelanceReinh — Wed, 11 Nov 2020 13:42:50 GMT

Hi @PeterClemmensen,

You can save a lot of white space by omitting what was likely meant as "code indentation":

%macro m;
   %do i=1 %to &t.;
&&x&i
   %end;
%mend;

The values are now separated by single blanks (rather than seven blanks) in %m, which gets you far below the 65534-character limit and thus avoids the error messages.

129  %put %length(%m);
48893

Re: Macro variable resolution

Tom — Wed, 11 Nov 2020 13:49:48 GMT

If you use the :var1- syntax to generate multiple macro variables the values are automatically trimmed.

To impact the format used to convert a number into the string stored in the macro variable you can just change the format attached to the variable.

proc sql noprint;
select name,age format=z5. into :n1-,:a1- from sashelp.class;
quit;
%put |&n1|&a1| ;
%put |&n2|&a2| ;

742   %put |&n1|&a1| ;
|Alfred|00014|
743   %put |&n2|&a2| ;
|Alice|00013|

Re: Macro variable resolution

PeterClemmensen — Mon, 16 Nov 2020 14:44:33 GMT

Thank you all 🙂 Makes more sense now