09-10-2011 03:02 AM
Thank you in advance.
09-10-2011 05:41 PM
I wasn't going to respond to your question as I don't think it is really answerable. The macros, in both cases, are the same .. the only difference would be the work you have to do to ensure that you can access them from the environment(s) that you need to. Autocall is simply the assignment of a location where macros can be found. A stored process, on the other hand, can be any collection of sas code, macros, procs, what have you, that can be accessed from a number of sources including EG.
You can find a number of hits regarding SAS stored processes on the web, as well as an incredible number that talk about the SAS macro language. Learning about each, as well as the equally new proc fcmp to create user functions, and executing code via call execute, cannot (at least I don't think) be described in a simple post response.
09-11-2011 01:00 AM
Art is correct. This is a vague question. WHAT stored process macros do you mean?? Something user-written? Or, do you mean the SAS supplied %STPBEGIN and %STPEND macros that are very often used to turn a "regular" SAS program into a program that can be executed as a stored process?? For information about %STPBEGIN and %STPEND macros programs, refer to the stored process developer's guide in the BI Platform documentation.
09-11-2011 10:24 AM
Not that I actually have an installation that can create or run stored processes, but to me the main difference is how the parameters are passed.
In an autocall macro you are allowed to define parameters in the %MACRO statement. And you specify the values when you write the code to call the macro. The parameters appear as local macro variables.
With a stored process the parameter values are assigned to global macro variables and then the stored process program is called.
This is similar to other system for calling SAS programs such as SAS/Intrnet or Oracle's Life Sciences Hub.
Calling an autocall macro:
Calling a stored process:
09-11-2011 12:43 PM
Of course, using %LET that way means that you ALWAYS want PARM1 and PARM2 to receive those values instead of what might be supplied by the client application that invoked the stored process. And, you may or may not want to use %INCLUDE -- %INCLUDE can include code snippets -- it does not have to include a program with a call to a macro program. This is an equally valid way to create a stored process:
%global parm1 parm2 _odsstyle;
In this instance, _ODSSTYLE would be ALWAYS set to SASWEB for those client apps that used style definitions and style changes. PARM1 and PARM2 would be set by the prompting interface for the stored process via the client application (instead of using %LET). The macro %MYMACCALL; would be invoked and assuming that it was stored in the appropriate autocall or stored compiled macro location defined to the servers in the metadata. Because the macro call is within the %STPBEGIN/%STPEND macro "sandwich", it is likely that the code generated by the macro call will create report output that needs to be routed back to the requesting client application.
09-11-2011 02:01 PM
I think you missed my point. An autocall macro is written as a MACRO where as a stored process is written as a PROGRAM.
When writing a MACRO you typically want to define the parameters into the macro definition. But when writing a PROGRAM you will have to treat your parameters as externally defined macro variables.
Am not sure how stored processes can access macro such as the %MYMACCALL in your example program. I assume that they are either defined in some setup field that defines what directories on the server to search or are perhaps %INCLUDED during the execution of the %STPBEGIN macro.
09-11-2011 02:34 PM
OK. I see the distinction you are making. A stored process is a SAS program, but like any SAS program, it can consist of 1 statement, multiple statements, 1 procedure call, multiple procedure calls, DATA step program(s), etc and, a SAS program can contain either a macro definition or a call to an existing autocall macro program or a call to a stored, compiled macro program.
In my example, the macro call %MYMACCALL; is possible in the stored process context, because the Lev1 folder in the BI configuration should have a SASEnvironment subdirectory and other directories for format libs (SASFormats), and macro programs (SASMacro). This is part of the configuration that happens when your BI platform is installed and configured. Macro programs that you use can be session compiled, autocall macro programs or can be stored, compiled, macro programs.
There is another directory for SAS code snippets (SASCode) which are meant to be %INCLUDEd if you are using %INCLUDE. %STPBEGIN/%STPEND are self-contained macro programs designed specifically to capture results from any code contained within the 2 macro calls -- they do not "read ahead" to see what my code might need or do. %STPBEGIN would not %INCLUDE anything for me.
My point was that the term "stored process macros" in the original question was not well defined (as we see by the various interpretations and responses). For another example, this is a perfectly valid stored process PROGRAM:
proc print data=sashelp.class;
title "My Stored Process Title";
However, in the above program, there are 2 macro calls: one call to invoke %STPBEGIN and another call to invoke %STPEND when the PROC PRINT is finished. The above program does has NOT been programmed to use any parameters coming from the client application prompting interface.
On the other hand, this is a perfectly OK stored process, too:
proc print data=sashelp.class;
title "My Stored Process Title";
I would say that the above stored process defines a macro program and then, immediately invokes the macro program in such a way, within the special construct of %STPBEGIN/%STPEND, that the PROC PRINT results will be returned to the client application that invoked the stored process.
You are correct where you say that when a programmer is writing a macro program, for general use, the parameters are usually defined as part of the macro program and sometimes, you put the default values for the parameters into the definition, too. But, if a programmer is writing a macro program for use within the stored process context, you have to change how your parameters are defined and how default values are set -- you now do those things as part of the process of defining the metadata for the stored process. If you have %LET statements hard-coded or if you have parameter values as part of the macro definition, you could accidentally clobber the values that are sent from the prompting interface used by the client application.
Existing macro programs that are going to be converted for use within a stored process context need to have all their parameter definitions examined for whether the parameter should come from the prompting interface or not. This may require removing parameter definitions from the %MACRO statement and/or removing %LET statements from the macro program code.
Since the OP has never clarified what was meant by "stored process macros", it's hard to guess whether the question has been answered or not.
09-12-2011 05:22 AM
Hi Cynthia, Sorry for late reply. I thought Stored Process is a macro so I mentioned it as Stored Process Macros. But after your reply, I understood that it is only a Stored Process . So there are no Stored Process Macros like Autocall macros. Thank you for giving some basic fundamentals about Stored Process.
12-20-2012 04:31 PM
Agreed but what about %include of sas u can store sas code some where and include that in your session how is it different from that please let me know
12-20-2012 06:01 PM
When you have a local copy of SAS and do a %INCLUDE, you can include code snippets, or whole programs from your computer's drive or from a shared drive. When you run a stored process, first your stored process does NOT run on your local machine. It runs on a Stored Process Server or a Workspace Server. So when you have a stored process which contains a %INCLUDE, the Platform configuration process has some directories that are recommended down in the Lev1/SASEnvironment folder -- one directory is for autocall macros, another directory is for format libraries and a third directory is for SASCode, such as you might %INCLUDE.
In your local session, you, as a programmer can write a program which will include code from any machine that your SAS session can get to. However in a stored process you don't, technically, have a "session" under your personal control, you request a stored process to execute and in the metadata, the appropriate server session is started up, but you really don't have a chance to see anything going on in the session. If your stored process has a%INCLUDE, it cannot use code on your local C drive. It must do the %INCLUDE from a location that is known to the server where the stored process will be running. The Platform config provides you this location.
Conceptually, %INCLUDE will include code in both scenarios. Where SAS is running will make a difference in how you build the %INCLUDE reference.