02-22-2011 04:21 AM
02-22-2011 04:56 AM
03-22-2014 10:58 AM
UNC (\\servername\sharename\subdirectory) is a WINDOWS naming convention. Your SAS session is running on a Unix machine. You need to ask the administrators for your Unix machine (or your SAS adminstrators) if that Windows filesystem is visible from the Unix machine. If it is use the Unix path for the files. So you would then translate the path from:
to something like
Where '/windows_share' is where the "N" drive is mounted on the Unix server.
Don't worry to much about the / or \ in the middle of the path name as SAS is happy to convert these for you. You can use / on Windows and \ on Unix and SAS still knows what you mean. But you have to be able to find the disk first.
03-22-2014 06:35 PM
I believe Tom has given you the explanation why your path isn't working. In general: The SAS code generated by DIS executes on the server you're connected to. That's why you need to define paths as they are "seen" and accessible from the server and not how you possibly see them from your client.
It's not good practice with DIS to use fully qualified path names. The reason is that you're very likely developing in a DEV environment but then promote your job to TEST and PROD. The paths will likely change between the environments and you should also allow for your %included code to have a DEV, TEST, and PROD version (eg. /rootpath/Lev3/projectpath..., /rootpath/Lev2/projectpath/...).
You must code in a way that you can promote your codes to a higher environment without the need for any code changes so you should at least use a macro variable for the 'Lev' bit - and this variable should be defined in the project specific autoexec.
You call the SAS file you want to use "macros.sas". If this is a SAS macro then even better would be this code is stored under a SAS Autocall Library SAS(R) 9.4 Companion for UNIX Environments, Third Edition
This way you don't need a path at all in your DIS job.
You should also try and avoid user written code. If you believe you have to call this macro in more than one DIS job then consider to implement by creating a User Transformation. I normally then simply call the macro in such a transformation and define prompts for the parameters to be passed in.
03-21-2014 02:44 AM
I am not sure is your path was created as display in here or what but it seem your folder have space, some symbols might not work. some physical path can't read space except %20, normally what I did is add "_" on each space. this might work for windows path, I am not sure about unix
03-21-2014 03:18 AM
This post raises a couple of questions.
First, are your Workspce server executing on UNIX?
Are yo aware of the concept of DI Studio as Java client, and not local SAS install?
If you need to access data outside the UNIX box, you need to speak with sysadmin for your Server.
From a design point of view, have never come across the need to %include any separate SAS code from a separate drive from a single job. If this folder contains macros that could be used widely in the warehouse, make them available using either options in the appserver_autoexec_usermods.sas-file, or move them to SASApp\SASEnvironment\SASMacro\.
03-21-2014 05:47 AM
Your workspace server runs on UNIX, so you have to make the include visible to it.
- UNIX knows NO backslash in Filepaths, instead it uses the forward slash. (actually it's the other way round, some bespectacled lawschool dropout decided to use the \ when he imported the idea of a hierarchical filesystem from UNIX into a new version of CP/M 86, which he later named DOS)
- if your UNIX server can see the PC network (Novell or AD), ask the admin what the name of the network mount is
- if your server cannot see the network drives, copy the files via ftp/sftp to your home directory there, or a publicly accessible location if other users should also be able to use the include
- start your filename with a / (or something like $HOME), so that it is interpreted as an absolute path. Without a leading slash, the working path of the workspace server is always prepended (the /some/unix/path/ that you saw).
03-21-2014 12:32 PM
a/ As you have DI it using a workspaceserver.
b/ A workspace-server can be used with EGUIDE.
c/ Eguide is offering a folder structure storing code egp on the UNIX-side somehow like Windows.
Why do you not use Unix (Linux or whatever OS) in the same way as being used on Windows?
Ask for a filename definitions in the APPServer at you admins. You can concatenate Filenames
By that you are getting a %inc <filename>(<source>) ; construct to get managed source-code into you programs.
Take care wiht upper/lower case Unix is case-sensitive and Windows not.