I have two different SAS platforms and I run a macro on each platform to create a report.
I use
%include "&MACRO_Path.";
what do i want is creating an automatic variable "MACRO_PATH" which contains file location. So when I start my SAS session, I do not need to define the file location in that MACRO_PATH variable.
I know one way is I can create auto executable file in the location which contains the code line but just wondering if I can create automatic Macro variable.
I, also, know automatic macro variables are the ones which are created by macro processor.
But is there any work around?
If you just have two hosts and you know which ones they are then you might be able to use SYSSCP or SYSHOSTNAME. For example if one is a Windows host and another a unix host you might do this.
%let macro_path=%sysfunc(ifc(&sysscp=WIN,c:\mymacros,~/mymacros));
If you're using Enterprise Guide, you can do this at the project level by using the Autoexec process flow. Name one process flow "Autoexec" and select the option that automatically runs that process flow when you open the project.
What I typically do for projects where I have, say, Dev, Test, and Prod environments, is to have linked files that are not synced in version control, stored in the project directory (you need to enable Relative File Paths in the Project Properties under File References). That contains the value for the macro variable(s) that are specific to the environment.
Then, that shortcut is stored in the autoexec process flow. The project itself is in version control, so when I sync my dev changes with test or prod it has the correct local references.
Related
I'm taking over a project from a coworker that involves several extensive SAS process flows. I have all the files with all the same names and a copy of the process flows they used. Since the file paths in their processes are direct references to their computer, normally I would just re-import the files with the same output names and run the process from there. In a few cases I would have to recreate a query builder as I'm using a few .sas7bdat files from another project.
However, there are quite a few files involved and I may end up having to pass this to another coworker in a few months, and since I can't get a good look at exactly what the import task is doing I'm concerned I may have some of the variables imported incorrectly. Is there an easy way to just change the file path the import or other task refers to?
Given the updates in comments, there's two possibilities I see.
If the paths you're changing are, or can be, relative to the location of the EGP, then you can right click on the Project->Properties->File References and check "Use paths relative to the project...", which means instead of storing a file in c:\my EGP folder\my code folder\code.sas it would store it as my code folder\code.sas. So then if the whole project moves to another computer (or just any other folder) then it automatically has the right path. This is mostly useful for code or similar things.
Otherwise, you're going to have to convert things to SAS code modules. There you can use macro variables to define the locations of things.
Basically when I do sorting or join table in sas, the sas will use resources / space from local disk C: to process the code, but since I only have 100GB left on local disk C:, It will result in error whenever SAS was out of resources.
My question is how to configure / change the setting in SAS to use resources from Local Disk E: instead, since I have larger space there.
I already looking through the forum, but found no similiar question.
Please Help.
Assuming you are talking about desktop SAS, or a server that you administer, you can control where the work and utility folders are stored in a few ways.
The best way is to use the -work and -utilloc options in your sasv9.cfg file. That file can be in a few places, but often the SAS Shortcut you open SAS with specifies it with the -CONFIG option. You can also set the option in that shortcut with -WORK or -UTILLOC command line options. The article How SAS Finds and Processes Configuration Files can help you decide the location of the sasv9.cfg you want to modify; if you are using a personal copy on your own laptop, you may change the one in the Program Files folder, but if not, or if you don 't have administrative rights, you have other places you can place a config file that will override that one.
A paper that discusses a few of these options is one by Peter Eberhardt and Mengting Wang.
One way is to set up a library named user for projects that will be time intensive and this way you get it to be dynamic as needed. When you have a library called user, that becomes the default workspace instead of work. But, you need to clean up that library manually, it won't delete data sets automatically when you're done with it.
libname user '/folders/myfolders/demo';
As #Tom indicates, you can also set an option to use a library that already exists if desired.
options user = myLib;
An advantage of this method over the config file method as it only does it for projects where it's needed, rather than your full system.
In SAS using SASMSTORE option I can specify a place where the SASMACR catalog will exist. In this catalog will reside some macro.
At some moment I may need to change the macro and this moment may occure while this macro and therefore the catalog will be in use by another user. But then it will be locked and unavailable to be modified.
How can I avoid such a situation?
If you're using a SAS Macro catalog as a public catalog that is shared among colleagues, a few options exist.
First, use SVN or similar source control option so that you and your colleagues each have a local copy of the macro catalog. This is my preferred option. I'd do this, and also probably not used stored compiled macros - I'd just set it up as autocall macros, personally - because that makes it easy to resolve conflicts (as you have separate files for each macro). Using SCMs you won't be able to resolve conflicts, so you'll have to make sure everyone is very well behaved about always downloading the newest copy before making any changes, and discusses any changes so you don't have two competing changes made at about the same time. If SCMs are important for your particular use case, you could version control the macros that create the SCMs and build the SCM yourself every time you refresh your local copy of the sources.
Second, you could and should separate development from production here. Even if you have a shared library located on a shared network folder, you should have a development copy as well that is explicitly not locked by anyone except when developing a new macro for it (or updating a currently used macro). Then make your changes there, and on a consistent schedule push them out once they've been tested and verified (preferably in a test environment, so you have the classic three: dev, test, and prod environments). Something like this:
Changes in Dev are pushed to Test on Wednesdays. Anyone who's got something ready to go by Wednesday 3pm puts it in a folder (the macro source code, that is), and it's compiled into the test SCM automatically.
Test is then verified Thursday and Friday. Anything that is verified in Test by 3pm Friday is pushed to the Dev source code folder at that time, paying attention to any potential conflicts in other new code in test (nothing's pushed to dev if something currently in test but not verified could conflict with it).
Production then is run at 3pm Friday. Everyone has to be out of the SCM by then.
I suggest not using Friday for prod if you have something that runs over the weekend, of course, as it risks you having to fix something over the weekend.
Create two folders, e.g. maclib1 and maclib2, and a dataset which stores the current library number.
When you want to rebuild your library, query the current number, increment (or reset to 1 if it's already 2), assign your macro library path to the corresponding folder, compile your macros, and then update the dataset with the new library number.
When it comes to assigning your library, query the current library number from the dataset, and assign the library path accordingly.
I have several (15 or so) builds which all reference the same string of text in their respective build process templates. Every 90 days that text expires and needs to be updated in each of the templates. Is there a way to create a central variable or argument
One solution would be to create an environment variable on your build machine. Then reference the variable in all of your builds. When you needed to update the value you would only have to set it in one place.
How to: Use Environment Variables in a Build
If you have more than one build machine then it could become too much of a maintenance issue.
Another solution would involve using MSBuild response files. You create an .rsp file that holds the property value and the value would be picked up and set from MSBuild via the command line.
You need to place it into somewhere where all your builds can access it, then customize your build process template to read from there (build definitions - as you know - do not have a mechanism to share data between defs).
Some examples would be a file checked into TFS, a file in a known location (file share), web page, web service, etc.
You could even make a custom activity that knew how to read it and output the result as an OutArgument (e.g. Custom activity that read the string from a hardcoded URL).
The debug settings are stored in a .user file which should not be added to source control. However this file does contain useful information. Now I need to set each time I trying to build a fresh checkout.
Is there some workaround to make this less cumbersome?
Edit: It contains the debug launch parameters. This is often not really a per-user setting. The default is $(TargetPath), but I often set it to something like $(SolutionDir)TestApp\test.exe with a few command line arguments. So it isn't a local machine setting per se.
Well, I believe this file is human readable (xml format I think?), so you could create a template that is put into source control that everyone would check out, for instance settings.user.template. Each developer would than copy this to settings.user or whatever the name is and modify the contents to be what they need it to be.
Its been a while since I've looked at that file, but I've done similar things to this numerous times.
Set the debug launch parameters in a batch file, add the batch file to source control. Set the startup path in VS to startup.bat $(TargetPath).