Am unable to store a macro

[deleted_user]

I am trying to save a macro to a directory I have created on a SAS server.

Here is the code I am using:

libname mjstore “C:\SASMacros\”;
options mstored sasmstore=mjstore;
%macro sortDS (in=, out =, by=) / store source des="get sortDS macro“ ;
proc sort data = &in.
out = &out. ;
by &by. ;
run ;
%mend sortDS;

When I run the code, it just keeps running and running. I get no errors. If someone can tell me the error of my ways, I would be grateful. Thank you in advance.

[Cynthia_sas]

Hi:
There is a difference between stored, compiled macros (which use the MSTORED and SASMSTORE= options) and using AUTOCALL macros (which use the MAUTOSOURCE and SASMAUTOS= options). With stored, compiled macros, you are storing a pre-compiled SAS macro program -- where the macro code has been compiled and is ready to be invoked. With AUTOCALL macros, you are storing the UNCOMPILED .SAS code (essentially what's between the %macro and the %mend). The AUTOCALL macro method allows you go compile the macro when you "need" it or "call" it.

In the Enterprise Intelligence Platform, there is an AUTOCALL location that the metadata server already knows about
SAS-config-dir/Lev1/SASMain/SASEnvironment/SASMacro
and, if you put your autocall macro in this location, then the appropriate options are already in place so that this location is automatically used. If you look in this Platform Administration manual
http://support.sas.com/documentation/configuration/bicag.pdf
and search for AUTOCALL, you should find some information about storing your macro code in this location. Look on page 525, starting at the section called the SASMAIN SubDirectories.

You might consider contacting Tech Support for help, especially since your macro usage is involved with the Enterprise Intelligence Platform issues of putting files on the server where they can be found from inside a stored process -- and whether a stored compiled macro is the correct type of macro to use in your particular operating system configuration.

cynthia

[deleted_user]

Hi, Cynthia,

The sample macro I was trying to save came from a white paper at this link:
http://www8.sas.com/scholars/05/SESUG_05/Proceedings/2005/AppsDev/AD07_05.PDF on pages 5 and 6. I am trying to figure what was not done properly, so I can avoid this kind of problem in the future.

It looks like what was in the white paper conflicts with what you said. The white paper indicated to apply the MSTORED and SASMSTORE= options, but you say to use the MAUTOSOURCE and SASMAUTOS= options. However, since your solutions have worked so wonderfully for me in other issues, I'm sticking with what you say.

Thankyou for your help - it's a tremendous asset.

[Cynthia_sas]

Hi:
As I said in my other post, there IS a difference between stored compiled macros and AUTOCALL macros. The key thing to note is that this paper is talking about how macros work in "regular" SAS and not in an Enterprise Intelligence platform context. In this paper, the author presents 3 different methods for dealing with macro programs and macro code -- each method has advantages and disadvantages.
Method 1) %INCLUDE of code (not necessarily macro code)
Method 2) AUTOCALL macro programs and
Method 3) stored compiled macros

The 3 methods aren't mutually exclusive, but IF you're going to use AUTOCALL, then you generally need the MAUTOSOURCE and SASMAUTOS options. IF, however, you are going to use stored compiled macros, then you would use the MSTORED and SASMSTORE options.

On page 6 of the paper, the author says that stored compiled macros have the following disadvantages:
"• Cannot be moved directly to other operating systems.
• Must be saved and recompiled under new OS at any new location."

That is one of the reasons why I recommended that you contact Tech Support. I do not even know if the Enterprise Intelligence Platform developers recommend the use of stored compiled macros for stored processes. What if you have mixed Linux and Windows servers? I'm not sure the stored compiled macros would work on any operating system other than the operating system they were originally compiled on.

In the Enterprise Intelligence Platform context, on the other hand, IF you use AUTOCALL macros and IF you stored your (uncompiled) .SAS macro code in an AUTOCALL location that is defined to the metadata server, then you do NOT need any extra options -- the metadata server knows how to find the AUTOCALL location -- all you have to do is store your (uncompiled) macro program there. If you were going to store your macro programs in some other location on the server than the predefined AUTOCALL location, then you would need to use the SASMAUTOS option to establish the search path for macro code. You have to be very careful here, because you do not want to clobber any SASMAUTOS option that might already be in effect on the server. This is the second reason I recommended that you contact Tech Support -- they can tell you how to find the SAS startup file that will show you what SASMAUTOS might be in effect for your servers.

I searched the PDF of the Platform Administration documentation and I found references to special places to stored SAS code for %INCLUDE and I found references to special places to store macro programs in an AUTOCALL location. I did NOT find references that explained about using stored compiled macros in the Enterprise Intelligence platform. Just because stored compiled macros is the last method outlined in the paper, doesn't mean that it's the best choice for your situation, especially with the Enterprise Intelligence platform thrown into the mix.

While I agree with the author of this paper that stored compiled macros are exciting, in my over 20 years of experience, I have mostly worked in shops where we used %INCLUDE and AUTOCALL macros or session-compiled macros (where the %macro and the %mend and the invocation are all in the same program). The number of places where I've used AUTOCALL far outnumber the places where I've used stored, compiled macros. This is probably because I've mostly worked in shops where code needed to execute on multiple operating systems.

cynthia

[deleted_user]

Good morning, Cynthia,

Points well taken. I just thought that option 3 sounded like the best way to go. Your issues are well laid out. At my shop, we don't have to worry about mixing / crossing of platforms - we're Microsoft oriented. So....off to find out more about MAUTOSOURCE and SASMAUTOS!

Thank you for your information.