Unable to export data to local folders (PROC EXPORT in SAS EG)

[DrBoogie]

Thank You Jaap,

now I see that I can't avoid this: "get this to your platform-admin (unix) guy....".

I wished I could because this guy sits 3000 miles away from me and usually don't respond to my emails (so I have to ask my boss to take influence...).

[jakarman]

@Drboogie,  See some fun in this thread/reply. Ik know some people in this community altough they are often using unclear names. The not that amazing point is they are comming from all over the world. 

You can find me very easy on linkedin. I gues the distance will be the same ammount statue miles. The Maximum of 10800nm/20000km is sometimes approached.  Distance should be no limitation.

The platform role is a more difficult one. It is sometimes positioned as IT only sometimes as busines only the promotion of SAS (some blogs etc) they should fill the gap between them. Looks some expectations on that has not been fulfilled at your site/service.  

[janetts]

I had that problem too, until I read the solution provided by Cynthia@SAS below. 

[kconnors]

Did you ever find a way to accomplish this?  I can easily get SAS EG to export the contents of a dataset from a library on a remote UNIX server to an Excel file on my local Windows hard drive using the Export task, but I haven't been able to find a way to get EG to expose the code that it uses to accomplish this.  The closest I have seen requires the use of the Copy Files task created by Chris Hemedinger; its use to accomplish this is described here: http://proc-x.com/2013/05/export-and-download-any-file-from-sas-enterprise-guide/.  It would be nice to be able to accomplish this all in code.

[SASKiwi]

EG can do it because it handles the download of the file from the SAS server to your PC. For it to work in code, which runs on the SAS server, the server must be able to reterence your PC and hard drive. As explained above by Cynthia this is done via a UNC: \\pcname\directory\subdir\

If you can get your Unix admin folks to make this happen then yes it will work in code. In summary this is a network access problem not a coding issue.

[kconnors]

Thanks, SASKiwi.  I was missing the fact that code can run only on one server.  An EG (custom) task can handle the download of the file from the SAS server to the PC in this because it is running locally on the PC, not on the server; Chris H's example uses the task to download the exported file after the exported file has been created on the server.  EG's Export task is likely taking the same approach.

[jakarman]

kconnors you are more likeIy to find a way  that integrates Windows/Unix better. These options:

1/ Client Server install using a SAS-server with connect is an option (most functionality).

    As the SAS windows server will need to get across Servers in your domain not being isolated to his own local machine, there are still security challenges to solve.

    The license cost could be a hurdle with the need of staff capable supporting that.

2/ Client Server install using a SAS PC- fileserver. This one comes with the SAS/access to pcfiles on Unix license.

    Still needing an additional Windows server install for that.  http://support.sas.com/documentation/cdl/en/pcfsicg/67728/PDF/default/pcfsicg.pdf

3/ Other tools like SFTP or NFS.

   The usage of EGuide as operational processing tool should be avoided. It is developers tool.

   When there is a SFTP server active in the Windows domain you can create a file on Unix and send it by sftp.

   NFS  (Samba)  is only an option with non sensitive data and not really professional managed services.

   There as security pitfalls with those and by those not easy accepted with reviews. wizards

By the way why are you using import wizards with Eguide. The process is data is converted by Eguide (VB processes) into a SAS datastep the datastep is uploaded and processed at the server.

The alternative is drag and drop files from the windows explorer to a files-tab of the server connected visiable in Eguide.  I am supposing XCEED-dll-s are behind those binary uploads.

Having the data at Unix it can processed there with optimized code for that.

[AndrewHowell]

The code you are submitting is run on the server, which means it will try to export it to a file-system on your server (i.e, NOT on the client where you are running Enterprise Guide).

Code only works where there is a SAS session running - in this case, the server. Enterprise Guide does not in itself execute code - it can store code, even prepare code from various task, but it then submits the code to a SAS session somewhere, and it is that SAS session which executes the code, returning logs, etc back to EG. Unless there is a local SAS session on the workstation, a "code only" solution is unlikely.

If you wish to save files on a local filesystem where there is no local SAS, you should use the client-based capabilities of Enterprise Guide - right-click on a table, and Export (or Export as a Step if you want a repeatable process.)

As an aside, it is possible for your SAS Administrator to set up user roles which can prevent uploading/downloading local files to/from a SAS server. This is NOT your issue (your code clarifies this), although it was the first thing I thought when I read your message subject.

[AndrewHowell]

Also, given where it tried to save your text file (in the Application Context configuration folder), I'm actually very glad it failed with in Insufficient Authorisation error - you might suggest to your SAS Admins that the default folder be redefined elsewhere. (SAS Management Console - SASApp Workspace Server - Properties - File Navigation)

[AndrewHowell]

Hmm - didn't see all of the previous responses before posting.. Mea culpa..

[jakarman]

Baloo you are working at a Unix system but using a Windows file name convention.

That will cause problems as the naming conventions are different. You cannot directly access windows that way.

You need to specify a correct Unix name.

The error message you got is showing an other issue.

The current dir is not your personal home like "my documents" but is a protected one part of the sas config. That's is a mistake of SAS there is a note on that.

The proc export usage by eguide task is a misleading one with Unix services.

[jakarman]

It makes sense is a tried to explain the network visibility and permissions are not functioning because, root cause: your are running the spawners by the local-system account.
LocalSystem Account (Windows) (microsof descrtption) It has for normal usage far too high credentials. And another The LocalSystem Account (Windows)    -  About the Local System Account/Computer$ in Configuration Manager

"The Local System account does not have any rights to access the network. When network access is necessary, Local System uses the account Domain\computername$."

Now see the iwa and requirement with trusts for networkresources SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition