09-17-2014 04:02 AM
With the file path of a SAS program file, you can automate a lot of things like libnames, macro autocall libraries, output destinations. The full file path name is available in Enterprise Guide, but only if the programs are stored on the server. I can save a SAS program on the server in the "Save As" dialog, in that case macro variable &_SASPROGRAMFILE contains the path name, e.g.
"C:\Users\<user name> \Documents\My SAS Files\9.4\<SAS program>.sas". I'm not a SAS administrator but apparently, a directory on the server is reserved for each user. This is the "Files" location you can see on the "Server List" pane, below the libraries.
But that's not really what we need, it has to be possible to access the SAS programs with Windows Explorer. So using the instructioons on http://bi-notes.com/2012/06/best-practice-for-centralized-user-storage/ out SAS administrator specified the "Files" location as a network share.
However, it turns out that if you open a SAS program from that network share, that &_SASPROGRAMFILE is still empty. If you right-click the program from the "Project Tree" pane and select "Properties", it will report the correct location of the file, this is the case whether or not the program is on the "Files" location. Only if you open the file from the server does &_SASPROGRAMFILE contain the correct file path. Interestingly, if you now right-click the program and look at properties, it reports "<SAS program>.sas [SASApp]".
So my question is, is there a way to derive the path name of a SAS program in EG if a file is simply opened from Windows Explorer? I've looked at the EG startup options, there doesn't seem to be anything to tell EG to ooen the file on the server. Perhaps EG could be scripted to derive the file path from a program's properties? Any other suggestions? I'm using EG 6.1 under Windows 7 and SAS 9.4 on a Windows 2008 R2 server.
09-17-2014 05:30 AM
You are trying to solve things you should hand over to others . Well you mentioned a SAS admin. He should understand you, IT en business policies.
Using SAS code with Eguide in a structured way is quite a challenge to do well, because:
- There are many locations code can be saved.
+ Within Eguide project (embedded)
+ Within a link to Windows location (can be made relative tot EGP saved location)
+ At the server in a OS based location (files) That is your bi-notes
+ At the server in SAS metadata
- SAS his own technical approaches for a lot of things, not always what is common habits.
- Going for release management and version management (policies) always getting into different insights.
- There are always SAS user and other IT-staff that are quite stubborn living in their own worlds not really cooperative how SAS works.
Your &_SASProgramfile only can be defined as soon as you have save the EGP and that location is known (relative path Windows only).
Your path "C:\USERS\<users>\..." is an OS based naming convention also common to Excel Word and all other user-friendly software. In a Unix environment it would be "/home/../<users>/..." This is at the edge of getting things to run with SAS, but not SAS specific.
What will happen is your EGuide project will store the full servers side path including your user-id in the EGP-project. That will be not the same as a shared drive connected to your desktop. If you want to achieve your code is reusable by other person this is a dead-end with all those physical naming everywhere.
What you could doe is:
- have an SAS admin defined a startup for you that defines all physical locations known to your SAS session by some macro-values or other settings
- Use the SP (stored process) approach for code that is validated and can be run that way
- use %include filref(yourcod.sas) as another method to include code from a physical location
Try to avoid physical namings in code (including users/passwords) as coding principle
09-17-2014 08:21 AM
Thank you for your reply.However, I don't fully agree with your comment that "SAS his own technical approaches for a lot of things". I would say that SAS has one way of doing things, Enterprise Guide has another.
I think I should first have explained the background. We're using SAS to analyse clinical trial data. Reproducability of the results is key and it's also important to be able to re-run sets of progams and save the logs. EG projects are not useful to us, we use SAS files and use EG as an IDE for developing programs, much as we would do in the Display Manager in regular SAS. Production files are run in batch mode using VBS scripts based on versions Chris Hemedinger placed online.
At present, we use a macro variable to specify a study folder location as a UNC path, e.g. "%let StudyDir=\\server\share\dir;". That has the disadvantage that this variable has to be modified if the file is moved, or a directory is renamed. In regular SAS, this wouldn't be a problem. You can get the full path and file name of a SAS syntax file using “%sysfunc(GetOption(SYSIN))” (batch mode) or “%sysget(SAS_EXECFILEPATH)” (interactive). This method does not work in Enterprise Guide.
It could be you're thinking of &_CLIENTPROJECTPATH when you say it's only avaiable once you save the EG project. I've looked into this as a solution but it didn't make me happy, being quite stubborn and living in my own world, not really cooperative with how EG works. In EG 4.3 at least, I would hav e to change the "File References" in "Project Properties" to make EG uses relative paths rather than an absolute path. Otherwise, the process still wouldn't work if the project location were to be changed. The process added extra overhead, the EG project had to be maintained, new programs added, old programs deleted. It's less work to just modify StudyDir.
I'd hoped that using a network share as the "Files" location on the workplace server would solve my woes, make it possible to just launch a SAS program from that file share using Windows Explorer and that &_SASProgramfile would contain the file location, like SYSIN or EXECFILEPATH in regular SAS. But as said, it doesn't work that way.
It's annoying that EG knows the file's location, even if it uses a drive letter the server won't understand. Why can't it just place that in a macro variable, I can easily change that into a UNC path in my program.
09-17-2014 05:28 PM
Hi ckx you can find my linkedin profile easy seeing a guy that did this kind of work a long time. auditability traceability described working processes like ITIL / Cobit (DTAP) and guidelines like iso27k are the things you are trying to achieve. These are the high level results of all kind of regulations. With that you should avoid those physical namings in SAS code that is what I said and what I see you are trying to do.
Using Eguide in Client/Server mode (files libraries on the server) you should also think that way.
All code is running on the Server started by scripts and options defined on the server. You have 9.4 there is a whole structure in the server-side found in the configuration dir.
The one that is important is named like \Lev1\SASapp\.... Below that one you will find directories like "Workspaceserver" "StoredprocesServer" "Batchserver" "connectserver"
Every directory contains files like a sas_usermods.cmd autoexec_usermods.sas config_usermods.sas (I am counting already 5*3 files).
You code and data can be organized in some different projects each with a lifecycle D develop T Test A Useracceptance P Prod for src / data objects (several of those types possible).
With Creating the data (or saving archiving results) also logs should be saved. I would say work as being common usage. You are doing almost the same.
You are not limited to a Lev1 you can also use Lev4,3,2,1 as D,T,A,P segregation. You can also define mulitipe SASApp servers for different projects. A lot is possible not knowing you are needing that and ready for that.
Back to that autoexec.usermods.sas file,
You can define
%let StudyDir=\\server\share\dir there or Preferable a Drive letter of the local Windows drive preventing network traffic.
or do a SET StudyDir=\\server\share\dir in the sas_usercmds.cmd file I prefer it to be in the cmd file as it can be reused in batch processing that way.
You can define ( the exalamation point is using the setting form the cmd-file (or config.sas file), are you having values in the autoexec use the &.
FILENAME StudyDir ( "!Studydir\Dev" "!Studydir\Tst" "!Studydir\Acp" "!Studydir\Prd" ) ; or
FILENAME StudyDir ( "!Studydir\Tst" "!Studydir\Acp" "!Studydir\Prd" ) ; or
FILENAME StudyDir ( "!Studydir\Acp" "!Studydir\Prd" ) ; or
FILENAME StudyDir ( "!Studydir\Prd" ) ;
This wil be different for each dedicated SASApp setup for an environment. This is concatenating of files see: SAS(R) 9.4 Companion for Windows, Third Edition (referencing External Files)
This is defining your project/code (and others) in that one location defined as generic start for each processing of your code. No need for any difficulties as you are trying to do.
What can you do in your code is %inc StudyDir(<yourcode>) ; No need for any physical naming no need to change is when running in an other stage of the DTAP.
What is the advantage of that concatenation? It is working like the Path statement searching the code using it in the first location to be found. So you can copy and DELETE (move) the code over the DTAP stages.
When everything is approved and placed into Prd Dev,Tst,Acp are empty. No rubbish left behind, being clear on the versions being used and no unintended mistakes by wrong changes in dev (nothing there) .
This is thinking on supporting users including Eguide users and projectmanagers by managing a server environment.
By the way you scheduling could be improved by real scheduling. It is a nice feature with Eguide 6.1 you can run code in parallel.
09-18-2014 10:54 AM
A useful post, I didn't know about the server options for configuring SAS and Enterprise Guide. I'm not sure though, how a program can determine where to write its output for example. The concatenated filenames will let a SAS program be included if a program by that name is in the production directory or if not, if the program exists in the test directory. But the program that's been read still won't know its location.
Things are certainly simpler in regular SAS where the program can just derive its pathname.
09-18-2014 11:29 AM
ckx you are wanting the physical location as some prove. A prove for what? When you will get audited the want to know the version (release) of your program the used data the resulted logging.
My argument is the physical location in not really relevant you should be able to answer those questions. I you look to other software they get marked (in the code/file) with some version indicator.
If you can prove the date/time stamp sizing of you code is a valid indicator you could use that one. Saving a list of that as some logging.
The program itself may not know its location but the caller is and that can all be logged in the sas-log file.
With a segregation between the development test and procution (operations staff) it makes more sense that physical location is not really relevant.
That is alo part of my growing up in the ICT. This was a common requirement in a somewhat bigger (still SMB) organization in 80's using Cobol and mainframe (assemble C SAS etc). The physical location was solved byt the people responsible for running the code (JCL). The same applies with sas with that batchserver (and all others) that are scripts running your code and should know all physical locations that includes places for loggings.
I say loggings as there a many more options to do logging with SAS aside that old regular SAS way. It is moving like a working approach as was common in that old days.
Sometimes figures are helpful. you could look at: DTAP lcm scm - soll ist, templates (I should improve that)