EG should understand windows paths

[tomrvincent]

I have a drive accessible to both Linux and Windows. 

So, I should be able to use 'S:/_Pennsylvania/Claims Processing/'

But no...I have to use '/mnt/nfs/prod/Teams/statutory/REGREP/_Pennsylvania/Claims Processing/' instead.

Also, if EG can import from my F drive (a Windows only drive), I should be able to use F in a proc import statement.  Same with export.

[Kurt_Bremser]

I see some merit in @Tom's idea:

Could SAS make an EG filename engine to allow the SAS server to talk to the Enterprise Guide user's machine? 

Perhaps similar to the PC-Files server? Or other engines like FTP, URL etc?

How about implementing this:

filename myfile iom 'C:\somepath\somefile';

This would then activate the local filereader of the IOM client and access the file in a manner similar to filename ftp.

What the user/programmer still needs to be aware of is the fact that the code from the import task/wizard can't be used as is, as EG not only copies the file to the server, but converts it on the way to a standardized format (that's why one can import Excel files without having ACCESS to PC Files licensed on the server).

[tomrvincent]

 @ChrisHemedinger can I call that task from within code?  Will it work with grid computing? Will it translate into a stored process? Will that stored process run within Excel?

I'm generally finding lots of problems running tasks and so, as a dept, we've decided to NOT use them except for development.  For QA and production, all tasks must be converted to code.

[ChrisHemedinger]

@tomrvincent - No, you can't call the Copy Files task in code.  It can work with Grid though, but not a stored process.  It's meant as a productivity tool within EG, but it's not a good fit for designing production SAS jobs that run in other environments.

The fact is that production jobs require you to factor in the data architecture/topology, and while some of these ideas might seem convenient when running within EG, none of them translate well to batch jobs or running in different environments.  Imagine you coded a "C:\MyData" libname in a stored process, and the SAS code magically translated the libname mapping to pull from your local drive.  How does that work when different users run it?

Plus, the idea of having an "IOM" engine that triggers a remote SAS session to reach back to your local drive -- that would run afoul of most modern security practices.  Microsoft Windows used to support something like this using DCOM, but various security updates eliminated that mechanism years ago.

[tomrvincent]

@ChrisHemedinger if the requirement was to refer to "C:\MyData", then I'd say it would work according to the requirement.

What I need is to be able to use the F, I, J and R drives that we have.  All I want is for SAS to support in code what you support in tasks. SAS should be 'bilingual'/'OS agnostic'...whatever you want to call it.  I should be able to use Windows paths or Unix paths or URLs or whatever and SAS should convert to whatever environment it is running in.

I should be able to do something like this:

proc import datafile="f:\accounting\2017\test.csv"...;  or  proc export outfile="/users/accounting/2017/test.csv"...;

and SAS would use each path.

[Kurt_Bremser]

And HOW, in $DEITY's name, should SAS know on its own that what you have mounted as J: on your desktop is mounted as /users on the UNIX server?

[tomrvincent]

@Kurt_Bremser same way EG does it now.  If certainly understands J: within a task and if it's running on Unix/Linux it can figure out /users as well.

Gotta say I love how you link money with deity. 🙂

[Kurt_Bremser]

EG doesn't do that AT ALL. It delivers a file to WORK and lets SAS read that. And EG does NOT know that /something on UNIX happens to be the same as J: on the desktop.

[ChrisHemedinger]

@Kurt_Bremser is correct.  EG, as a Windows app, knows the local file system (including mapped drives).  And SAS, on the remote server, can access the file system of the server machine and network-mounted systems.  Sometimes (ideally) it works out that you can use your Windows apps and your server programs to reference the same physical file, albeit using each of their own file schemes.  But EG cannot intuit that connection -- it's different everywhere and highly dependent on your network setup. 

Here at SAS we have the "U:" drive on Windows.  It maps to something like "/r/nfsnode/vol/vol910/u91/userid" -- that's just how our network team set things up.

You can approximate the function you want with macro variables.  Something like:

%let S_drive=/mnt/nfs/prod/Teams/statutory/REGREP;

/* more code */

proc import file="&S_drive./_Pennsylvania/Claims Processing/data.xlsx"
 /* more options */;
run;

You can safely use forward slashes in any file spec in SAS, and SAS will do the right thing on Windows and Unix.  

[tomrvincent]

@Kurt_Bremser sure it does.  Try importing a file.  It knows how to navigate the OS to allow you to select a file or you can even enter a fully qualified path and filename.  Try it.  Works just fine.

[Kurt_Bremser]

Absolutely not. It NEVER uses a path to a shared resource on its own. The EG import wizards ALWAYS COPY the files to the SAS session and have it read from there. Apart from the path to the WORK location and the file navigation point defined for the workspace server, they have no knowledge of the server's file system options. And the files in the server list require you to navigate.

And if you chose to not believe me, you might believe @ChrisHemedinger, who is one of the EG developers.