topic Re: Autocall macro library in EG / BI server in SAS Enterprise Guide

Autocall macro library in EG / BI server

Quentin — Fri, 08 Jun 2012 17:57:10 GMT

Hi All,

I'm a bit confused about how to define autocall macro libraries in EG/ BI server.

If I open EG (connecting to linux server) and do %put %sysfunc(getoption(sasautos)) I get

( "SASEnvironment/SASMacro" '!SASROOT/sasautos' )

So !SASROOT/sasautos is the usual environment variable pointing to .../sasautos, which has the autocal macros SAS provides (%left etc). It points to the same directory as the SASautos fileref.

But what is SASEnvironment/SASMacro pointing to? I'm not finding it on the server (and not sure where to look).

I ask because I wanted to add my own personal autocall library to the search path. Was planning to do this by adding:

options sasautos=("/home/mymacros/" sasautos);

As code to be submitted when server is connected.

But before I do that, wanted to make sure that there aren't any macros in "SASEnvironment/SASMacro" that I need (in which case I would need to keep this in the search path).

Thanks,

-Q.

Re: Autocall macro library in EG / BI server

Cynthia_sas — Fri, 08 Jun 2012 20:18:59 GMT

Hi:

I would not recommend tampering with the location of the SASAUTOS, especially in a BI configuration. Generally, the autocall macro library, along with the SAS formats location is defined to your servers -- you do not want to tamper with this. Even if it's empty, right now, you can't guarantee that your admin person won't drop a macro in there that needs to run under certain circumstances.

On my single user install, for example, my location is defined down in the Lev1 folder like this

(Windows install, local machine, no remote servers):

c:\SAS\Config\Lev1\SASApp\SASEnvironment\SASMacro

and there are these other directories, too:

c:\SAS\Config\Lev1\SASApp\SASEnvironment\SASFormats

c:\SAS\Config\Lev1\SASApp\SASEnvironment\SASCode

In the above, SASApp is the name of my application server context -- so this piece of the name might be different. The high level part of the path should be different, too. I would recommend that you speak with your SAS Administrator and/or Tech Support before altering your autocall path in a BI Platform install.

cynthia

Re: Autocall macro library in EG / BI server

Quentin — Fri, 08 Jun 2012 20:47:27 GMT

Thanks Cynthia,

Would you even recommend against just pre-pending a path to the current autocall search path (like this macro from Peter Crawford)?

That is, use soft code to determine the current autocall option in effect from whatever the SAS admin has defined, in my case would return:

( "SASEnvironment/SASMacro" '!SASROOT/sasautos' )

And then pre-pend my personal autocall library to that:

("/home/mymacros" "SASEnvironment/SASMacro" '!SASROOT/sasautos' )

In non-BI SAS, I think lots of people are in situations where there are hierarchies of macro libaries (SAS supplied->Corporate Macros->Project Macros), would be a shame in BI to give up on having project-specific autocall libraries. (And I would feel the same for pre-pending to fmtsearch to look for project-specific formats before looking for any server-level formats defined by an admin).

--Q.

Re: Autocall macro library in EG / BI server

Quentin — Fri, 08 Jun 2012 20:58:15 GMT

Actually just realized SAS recently made pre-pending easier without needing Peter's lovely macro. You can put insert on the options statement. This doesn't seem risky for BI, does it?

1 %put %sysfunc(getoption(sasautos));

SASAUTOS

2 options insert=(sasautos="c:\mymacros");

3 %put %sysfunc(getoption(sasautos));

('c:\mymacros' SASAUTOS)

Re: Autocall macro library in EG / BI server

ChrisHemedinger — Fri, 08 Jun 2012 21:01:41 GMT

Quentin, I think that's exactly what INSERT= was designed for. As long as your macros won't (unintentionally) obscure any of the others in the path, I think you're good.

Chris

Re: Autocall macro library in EG / BI server

Tom — Fri, 08 Jun 2012 22:20:14 GMT

Chris -

What is the answer to the original question. What is the "SASEnvironment/SASMacro" directory that is appearing the SASAUTOS option setting?

Where is it located? Since it does not start with a / it appears that it is a subdirectory of the current working directory. What directory is the current working directory for SAS code submitted through EG? What is creating the directory? What macros are stored in there?

- Tom

Re: Autocall macro library in EG / BI server

Tom — Fri, 08 Jun 2012 22:27:17 GMT

For years I have seen systems build using that bottom up search path.

For example you might have an application in SAS that has task directories nested in project directories so you might have a search path of

options sasautos=("&mytask" "&myproject" "&myapplication" sasautos);

The advantage is that your "local" level can override the definition of macros defined at higher levels.

Of course this is also a dis-advantage as a program for TASK1 might not work when moved to TASK2 because a common macro was redefined.

I have been thinking lately that it might be better to reverse that search path. Put the SAS supplied macros first and most local macros last.

Then you cannot override a macro defined at a higher level (at least not without explicitly writing or including the macro definition).

Re: Autocall macro library in EG / BI server

Cynthia_sas — Sat, 09 Jun 2012 00:26:36 GMT

Yes, I agree with Chris. If you use INSERT, I think you'll be OK. I would recommend that you pick some naming convention for your macros to prevent colliding with any other macros by haviing a unique name, then you should be OK.

cynthia

Re: Autocall macro library in EG / BI server

Quentin — Sat, 09 Jun 2012 04:25:09 GMT

Thanks much everyone. Lots to respond to.

@Chris and @Cynthia, appreciate your weighing in that INSERT feels safe. Glad to hear it. And appreciate Cynthia warning me against being bold enough to completely redefine sasautos. Seems like better to respect the SAS admin. : )

@Tom re SASEvenvironment/SASMacro, Thanks for the hints as to where I should look for SASEnvironment/SASMacro. You are correct, /SASEnvironment is a subdirectory of the current working directory. Because we have the X statement enabled, It was easy for me to find the working directory with just "x PWD;" whch revealed the working directory for my session in the server is [SAS-config-dir]/Lev1/SASApp. In there I see /SASEnvironment/SASFormats , /SASEnvironment/SASMacro , and /SASEnvironment/SASCode. I think /SASFormats is for format catalogs defined on the server (see e.g. http://support.sas.com/kb/40/103.html, which describes how this directory gets added to fmtsearch in the default install), and /SASMacro is the default server autocall library (for admins to add macro definitions that should be available to every sever session). In my case, both are empty. It looks like /SASCode has code for scheduled DI jobs. So this helps me understand Cynthia's point: if one day my admin did start adding macro definitions, I would want to them to be available to my programs. So completely redefining sasautos to exclude this directory would be a mistake.

@Tom re whether best order for sasautos search is (/project /corporate /SAS_supplied) or (/SAS_supplied /corporate /project), I'm a believer in the former. When I was responsible for setting up an install a year or so ago, I looked to SAS-L for some advice on this. I was convinced after a few emails that (/project /corporate /SAS_supplied) is the better option. Main points being that if you use the (/SAS_supplied /corporate /project) approach, any time there are additions to either the SAS_supplied or corporate macro libraries, you risk breaking your user's programs if there is a collision in macro names. People don't like when their programs work one day and not the next. So I think it's better to give the user's code priority. This puts more power in the hands of users, even allows them to redefine/hijack corporate standard macros if they want. Of course the name collision still can cause confusion (I look at the code for project X and assume the call to %MAC is the corporate standard %MAC, not knowing that it has been redefined), but at least the program works. The thread is: http://listserv.uga.edu/cgi-bin/wa?A2=ind1101c&L=sas-l&D=0&O=A&P=36772 .

Thanks again.

--Q.