Technology Tales

Adventures & experiences in contemporary technology

SAS Macro and Dataline/Cards Statements in Data Step

28th October 2008

Recently, I tried code like this in a SAS macro:

data sections;
infile datalines dlm=",";
input graph_table_number $15. text_line @1 @;
datalines;
"11.1           ,Section 11.1",
"11.2           ,Section 11.2",
"11.3           ,Section 11.3"
;
run;

While it works in its own right, including it as part of a macro yielded this type of result:

ERROR: The macro X generated CARDS (data lines) for the DATA step, which could cause incorrect results.  The DATA step and the macro will stop executing.

A bit of googling landed me on SAS-L where I spotted a solution like this one that didn’t involving throwing everything out:

filename temp temp;

data _null_;
file temp;
put;
run;

data sections;
length graph_table_number $15 text_line $100;
infile temp dlm=",";
input @;
do _infile_=
"11.1           ,Section 11.1",
"11.2           ,Section 11.2",
"11.3           ,Section 11.3"
;
input graph_table_number $15. text_line @1 @;
output;
end;
run;

filename temp clear;

The filename statement and ensuing data step creates a dummy file in the SAS work area that gets cleared at the end of every session. That seems to fool the macro engine into thinking that input is from a file and not the CARDS/DATALINES method to which it takes grave exception. The trailing @’s hold an input record for the execution of the next INPUT statement within the same iteration of the DATA step so that the automatic variable _infile_ can be fed as part of the input process in a do block with the output statement ensure that new records from the input buffer reach the data set being created.

This method does work but I would like to know the underlying reason as to why SAS Macro won’t play well with included data entry using DATALINES or CARDS statements in a data step, particularly when it allows other methods that using either SQL insert statements or standard variable assignment in data step. I find it such a curious behaviour that I remain on the lookout for the explanation why it is like this.

Comments:

  • ljo says:

    Hello,

    As matter of fact, the SAS documentation presents a warning relevant to your issue but I have to admit that it doesn’t say why it is like that and I don’t have the answer.

    “A macro definition must precede the invocation of that macro in your code. The %MACRO statement can appear anywhere in a SAS program, except within data lines. A macro definition cannot contain a CARDS statement, a DATALINES statement, a PARMCARDS statement, or data lines. Use an INFILE statement instead.” in Help / Macro Language Dictionary / %MACRO Statement, SAS V9.1

    But does it really matter? As you wrote it, there is always an alternative solution with SAS. And sometimes, I have to say it’s not always pertinent to put everything in a macro. A review of the way you are building your application/program can be the solution because it helps to get things done in a most understandable way.

  • John says:

    That warning in the SAS Documentation is certainly consistent with all that I have seen on the subject. It makes me wonder whether DATALINES, etc. would throw out the SAS Macro processor for some reason but I have yet to see that confirmed anywhere. Your comments on program design are certainly pertinent since I have been planning to get what I was creating to read in from a text file but that’s on hold pending the resolution of other things first.

  • All the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. As regards editorial policy, whatever appears here is entirely of my own choice and not that of any other person or organisation.

  • Please note that everything you find here is copyrighted material. The content may be available to read without charge and without advertising but it is not to be reproduced without attribution. As it happens, a number of the images are sourced from stock libraries like iStockPhoto so they certainly are not for abstraction.

  • With regards to any comments left on the site, I expect them to be civil in tone of voice and reserve the right to reject any that are either inappropriate or irrelevant. Comment review is subject to automated processing as well as manual inspection but whatever is said is the sole responsibility of the individual contributor.