how to export sas data into nestwork shared path

[vallsas]

Hi All,

I have SAS EG 8.3 on redhat linux server and using EG on my desktop(installed) to export the sas dataset into network shared path (ex: \\shared\dept\reports\) this shared path is window network path.

i am trying to export the dataset into this location by using proc export but the file with path is exported in "/opt/sas/lev1/saspp1/" location like "\\shared\dept\reports\cr.csv"  as file in sas datamanagemet server (saspp1). 

any body come across this kind of problem? please share thanks..

[LinusH]

Try to understand what you are writing, you try to export to \\shared\dept\reports\cr.csv, but it ends up in /opt/sas/lev1/saspp1/?

Is this on Linux/UNIX?

Can you make sure that the desired path is available from within your SAS session?

Please share the log.

[vallsas]

yes, I try to export the sas dataset into the  \\shared\dept\reports\cr.csv mentioned path but it ends up in the /opt/sas/lev1/saspp1 .

The environment is red hat Linux,I am using E.G on windows os. sorry currently log is not with me but i am sure the file is created in server path(/opt.et..). 

so I noticed in the log /opt/sas/Lev1/sasapp1/\\shared\dept\reports\cr.csv created with 2 records.

also some message 

in the log :NOTE: Unable to open parameter catalog: SASUSER.PARMS.PARMS.SLIST in update mode. Temporary
parameter values will be saved to WORK.PARMS.PARMS.SLIST.

[Tom]

---

@vallsas wrote:

yes, I try to export the sas dataset into the  \\shared\dept\reports\cr.csv mentioned path but it ends up in the /opt/sas/lev1/saspp1 .

The environment is red hat Linux,I am using E.G on windows os. sorry currently log is not with me but i am sure the file is created in server path(/opt.et..). 

so I noticed in the log /opt/sas/Lev1/sasapp1/\\shared\dept\reports\cr.csv created with 2 records.

also some message 

in the log :NOTE: Unable to open parameter catalog: SASUSER.PARMS.PARMS.SLIST in update mode. Temporary
parameter values will be saved to WORK.PARMS.PARMS.SLIST.

---

It is probably not good that it actually let your write a file into the directory.  In addition to asking the SAS and Unix administrators to mount your Windows share you should also ask them to improve the security on the /opt/sas/Lev1/sasapp1/ so that SAS users cannot write files there.  Otherwise some runaway SAS process might fill up that disk with garbage.

You can ignore the NOTE about SASUSER.  PROC EXPORT is just too stupid skip trying to use SASUSER when it is not writable.  (and also there is no reason it should even be trying to save that SLIST thingy).

[Tom]

So it looks like SAS is running on Unix.  (Enterprise Guide is just a PC program you use to allow you to submit SAS code to where ever the SAS server you current session is using is running).

And that the present working directory of the SAS session is the Unix directory /opt/sas/lev1/saspp1.  That sounds normal for a SAS application server that you might have connected to with Enterprise Guide.

When you give Unix a path, like  \\shared\dept\reports, that does NOT start with the root node (the leading / ) then it is interpreted as a RELATIVE path instead of an absolute path.  The \ character in Unix is used to escape the following character.  So \\shared\dept\reports would mean the file named /opt/sas/lev1/saspp1\sharedeptreports .

If you want SAS to be able to write to shared Windows network location \\shared\dept\reports then ask the system administrators on the Unix machine where SAS is running to MOUNT that as a directory in the Unix Filesystem.  Then reference it with the name they tell you to use.  So if the mounted it at the location /windows_shares/dept/reports then use that path in the SAS code.

[vallsas]

Hi Tom,

You understood my problem exactly and yes it is windows shared path and my server is Linux server and using E.G on my windows which connects to the Linux server where sas configuration is done.

I would like to ask/clarify if I ask server admin like please mount the following path on saspp1 server 

\\shared\dept\reports to /shared/dept/report ? (changing the '/'  and the same path).

[Tom · Accepted solution]

---

@vallsas wrote:

Hi Tom,

You understood my problem exactly and yes it is windows shared path and my server is Linux server and using E.G on my windows which connects to the Linux server where sas configuration is done.

I would like to ask/clarify if I ask server admin like please mount the following path on saspp1 server 

\\shared\dept\reports to /shared/dept/report ? (changing the '/'  and the same path).

---

Ask them to mount it an tell you what path you can use.  There is no universal standard naming convention for where to mount disks on Unix.  So they will follow their policy when deciding where to mount.

When referencing files on unix use the / to separate the sub-directory names.  (actually in general on SAS you can use / on both windows and unix in the SAS code and SAS will translate for you).

Also remember that on unix filenames are case sensitive.  So dept is different than DEPT and both could exist.

[jebjur]

Another option is to use the Enterprise Guide export GUI method to export a data set to Excel. With the data set open, you would select either Share -> Export or Share -> Export as a Step in Project, and then you can select the windows network location on your PC as the location to save the Excel file.

[vallsas]

yes, understood however I would like to schedule the program. 

[SASKiwi]

In which case stick with a SAS code solution like PROC EXPORT so you have the option of server-based scheduling which is much more reliable than PC-based scheduling.

[Sajid01]

First step check if the shared network path \\shared\dept\reports\  is accessible from your Linux machine . You can run the following code to see if the shared network path is accessible

libname testlib "\\shared\dept\reports\";

If the library is created you have access otherwise not. In all probability it will be it will be a no.

Speak to your Linux Admins / Steams to have the shared file system mounted  on the Linux Server with write access.
If this does not happen then SCP  or FTP clients will be the only feasible options.