BookmarkSubscribeRSS Feed
anil
Calcite | Level 5
Dear all,
Please help me in understanding these terms.
I feel each company can have their own 'standard (validated ?) macros' for routine use and are not usually shared.
It is rather difficult to write the same program again & again and validate (especially for TFL) it companies have their 'macro macros' which are validated,With minor modification they can be used in normal circumstances.
Thanks
Anil
2 REPLIES 2
Cynthia_sas
SAS Super FREQ
Hi:
I think that the term "standard macro" has come to mean something fairly specific in the pharmaceutical/research industries, as described in this paper:
http://www2.sas.com/proceedings/sugi31/018-31.pdf

From my standpoint, as an instructor, I categorize macro programs in much broader strokes -- there are SAS-supplied macro programs (such as
%LOWCASE or %LEFT or %VERIFY -- which are SAS-supplied "autocall" macro programs) and then there are user-written macro programs. Those user-written macro program could be simply assembled into a macro library for re-use OR they could be organized into an "application" or "system" for accomplishing analytical and reporting tasks.

Since the foundation of any SAS macro program is a working SAS program, consider this program:
[pre]
proc contents data=sashelp.shoes;
title "SASHELP.SHOES";
run;

proc print data=sashelp.shoes(obs=10);
title "First 10 obs from SASHELP.SHOES";
run;
[/pre]

Every time I create a file or access a file for the first time, I need to run the above 2 steps in order to document my access. Recoding those two programs over and over quickly becomes tedious and the programmer who knows about macro language will turn to the SAS Macro facility for a solution such as this:
[pre]
%macro doc_it(lib=sashelp, dsn=shoes, obsno=10);
proc contents data=&lib..&dsn;
title "&lib..&dsn";
run;

proc print data=&lib..&dsn(obs=&obsno);
title "First &obsno obs from &lib..&dsn";
run;
%mend doc_it;
[/pre]
and then every time documentation needs to be accomplished, the programmer has to submit statements to invoke the macro for their new data set:
[pre]
%doc_it(lib=work, dsn=wombat, obs=10);
%doc_it(lib=perm, dsn=employees, obs=50);
[/pre]
I would consider the above macro program to be a fairly simple utility macro program -- once I prove that the output from the macro program is the same as the output from the original SAS program, then I would consider the macro program to be validated.

When you are dealing with complex reporting and analysis requirements, if you are using the SAS Macro facility, you can develop quite complex, self-adjusting, macro programs -- no matter how complex your system is, you still have to start with a working SAS program in order to develop your macro code. Eventually, at some point, you have to show that your macro code produces the same output as the original working SAS program.

At that point, you have verified your macro code. Now, if you want to use the same set of macro programs (or a macro "system") for a new set of data (as for a new study or a new year), then as long as the macro programs were written with the flexibility to change data sets or even adjust for different columns (all possible with the Macro Facility) -- then the macro programs themselves only need to be re-validated if the underlying code changes. Only the workings of the macro programs with the new data needs to be validated -- i.e. does the macro "system" produce the same outputs with new data as it did with the old data.

I believe that the SUGI paper referenced above goes a long way to explaining what is meant in the author's example for "standard" macros and a macro "system" for routine use.

Since you have posted this question to the Stored Process Forum, however, I must point out that while a SAS Stored Processes COULD invoke a SAS macro program, a SAS Stored Process could just as easily be a simple .SAS program that is being surfaced via the SAS Enterprise Intelligence Platform client applications. A SAS Stored Process program can make as much or as little use of the SAS Macro Facility as the Stored Process author is comfortable using.

The places where SAS Stored Processes intersect with the SAS Macro Facility are these:
1) Stored Process parameters are passed to the various servers as SAS Global Macro variables.
2) Generally, SAS Stored processes include calls to the %STPBEGIN/%STPEND (SAS-supplied) macro programs, in order to set up the correct ODS environment for returning results to the different client applications.

Here is another reference to a standard macro "system" for performing complex analysis:
http://www.nesug.org/proceedings/nesug05/ap/ap1.pdf
If you are interested particularly in clinical trial or pharmaceutical research, a search of the papers on the PharmaSUG web site may prove useful to you. If you Google the search string: PharmaSUG papers macros the top hit is for a searchable web site that indexes papers from PharmaSUG as well as from other user group conferences: http://www.lexjansen.com/

cynthia
anil
Calcite | Level 5
Hi, Cynthia,

Your explanation cleared my doubts.

Thanks for replying!

Anil

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 2 replies
  • 1397 views
  • 0 likes
  • 2 in conversation