DATA Step, Macro, Functions and more

How to convert a normal code to 'stored process' code

Reply
Frequent Contributor
Posts: 86

How to convert a normal code to 'stored process' code

Hi All,

I written a some macro code...how to convert a 'stored process' code.

Thanks,

suresh

Super Contributor
Posts: 349

Re: How to convert a normal code to 'stored process' code

Hi Suresh,

You can do this easily by using SAS EG or SAS MC.If you dont have these clients installed then you can do this using Base SAS(but you need to register that code in metedata)

*Processbody;

%stpbegin;

macros statements...'

%stpend;

Thanks,

Shiva.

SAS Super FREQ
Posts: 8,864

Re: How to convert a normal code to 'stored process' code

Hi:

  I see that this question was also posted in the Stored Process forum:

https://communities.sas.com/message/129743#129743

  Here's a clarification/elaboration to the answer above. Since macro "statements" (such as %IF or %DO) cannot be used in open code, there are a couple of specific different things that are implied by macro "statements" and macro "code". Whether you are using macro variables or using a macro program, makes a difference in how you convert your code to a stored process. Generally with the stored process macro programs %STPBEGIN/%STPEND, you are creating a report with visible results to be returned to a client application (such as Word, Excel, Web Report Studio, etc). So if you had 2 macro PROGRAMS (%macpgm1 and %macpgm2) and let's say that one created some code for data manipulation and then created some code for PROC TABULATE then, since the TABULATE produces visible results that you want to send to the client application, the call to %macpgm1 should be INSIDE the invocation "sandwich" of %STPBEGIN/%STPEND. Then, if %macpgm2 also generated some SAS/GRAPH code, then it too should be inside %STPBEGIN/%STPEND. However, if %macpgm1 only generated the data manipulation code and %macpgm2 only generated the TABULATE and SAS/GRAPH code, then only the %macpgm2 call needs to be placed within the %STPBEGIN/%STPEND calls.

*Processbody;

%macpgm1  <--- only generates data manipulation code

 

%stpbegin;

%macpgm2    <---only generates TABULATE and GRAPH code, for example

%stpend;

   If you have an existing macro program definition and the macro definition is stored in an AUTOCALL library known to the BI Platform, then your program flow/conversion would look like this:

*Processbody;

%stpbegin;

%macpgm1   <--- this example would be used if both macro programs

%macpgm2   <--- are generating code which will produce "report" results

%stpend;

(where %macpgm1 and %macpgm2 were AUTOCALL macro program definitions)

 

If, you are going to COMPILE your macro program definition in your stored process, then, as a best practice, you should put your macro program definition outside of the %STPBEGIN/%STPEND macro calls. What you have inside %STPBEGIN/%STPEND should be "ready to go", so a macro program definition is better left outside of those other macro calls.

%macro macpgm1;

...more statements...

%mend macpgm1;

%macro macpgm2;

...more statements...

%mend macpgm2;

*Processbody;

%stpbegin;

%macpgm1

%macpgm2

%stpend;

Also, in the process of conversion if your macro program definition has parameters:

%macro macpgm1(parm1=, parm2=)

Then you will need to REMOVE from the macro definition any of the parameters whose values will come from the stored process prompting interface. This will avoid scope issues, where the prompt is a GLOBAL macro variable, but your macro program parameter is a LOCAL macro variable.

If your stored process program only uses macro variables, then this model is appropriate:

*Processbody;

%stpbegin;

proc print data=sashelp.class noobs;

  title "Stored Process Report for &gender students who are &age years old";

  where age = &age and sex = "&gender";

run;

%stpend;

cynthia

Ask a Question
Discussion stats
  • 2 replies
  • 196 views
  • 0 likes
  • 3 in conversation