Running SAS EG jobs in Windows from Unix

[JohnSimmons]

Good morning SAS Communities, and thank you for your help ahead of time!

We have SAS running on Unix, but are initiating all of our SAS Jobs from Windows.

My desire is to have one SAS job that runs all of my other SAS jobs (Allowing for one data pull against a database and a myriad of smaller reports to use this data subset).

I have built a convoluted process that uploads the EGP file onto the UNIX server, runs it, and then deletes it from the UNIX server, but I would like to cut this out if I can as it requires me to maintain numerous passwords, key pairs and such that would be inconvenient for another user to pick up should I get sick or something.

So, I have seen where people utilize the %include statement to run jobs on their windows machines, but I am having trouble with this, considering the perceived road block that I am having.

The code seems simplistic:

FILENAME networkDirectory '\\servername\pathname\';

%include networkDirectory(sasEGPFile);

This, however, errors out stating:

ERROR: Physical file does not exist: /unixpath/\\servername\pathname\.

ERROR: Unable to access the aggregate NETWORKDIRECTORY and therefore unable to %INCLUDE the member (sasEGPFile).

My fundamental problem (with both this and other things I have tried to do in the past) is being able to access the network from the UNIX machine.  I have successfully done this in the past utilizing FILENAME FTP, however it does not seem intuitive nor does it seem to work for this particular scenario since I am not trying to pull in a text or excel data source.

Thank you for any help or suggestions you can provide!

John

[Quentin · Accepted solution]

Hi,

I'm confused.

You mention a convoluted process which uploads a .egp file to the unix server, and runs it, then deletes it.  That should not be necessary.

You can store an .egp file on windows, open that file using EG on windows, have the EG session connect to your unix server, and then any code you submit in EG will be run on the Unix server for you.  One of the benefits of EG is that it allows you to access the power of a *nix sever without having to fuss much with *nix itself.  (I blogged about using EG as gateway to *nix:  http://www.bi-notes.com/2013/03/sas-enterprise-guide-unix-putty/ )

Regarding your %include statement, it sounds like you are trying to have code that is running on Unix server, then %include a .sas program stored on your windows server.  That will not work (unless you have gone though some extra steps to mount the windows server to your unix server).  In short, in order for the SAS session running on Unix be able to %include a file, you need to be able to see that file somehow from Unix.  If the Unix server can't see the file, a SAS session running on Unix can't %include it. 

If you have Samba running on the unix server (which makes unix files available to windows), I have found it easiest to just store my project code etc on the Unix server rather than Windows server.  Then it is easy enough to run/%include it from either PC SAS, EG, batch submit, etc.

HTH,

--Q.

[JohnSimmons]

Good afternoon Quentin,

Thank you for taking the time to respond to me.

The way our UNIX server is set up, only the user who creates the file can go in and edit it, though anyone can run it.  On the local network, anyone can access the files from our team and edit them.

The convoluted process was allowing me to pop an anyone-edited file up onto the UNIX server, run it from the main scheduler SAS job, and then remove it afterward so it doesn't take up space on the server we have allocated (this costs our team money and we don't have a lot of space or budget.)

I'm by no means saying this is the right way to do it, I am just saying this is what I have built based on my understanding of SAS as well as our limitations within our infrastructure.

It sounds like my best bet from both reading your reply and posted blog (thank you very much for both), that I need to try and get them to open up a team folder we can all edit with more space and start saving our EGP files out there to be run with (from your blog here), a symbolic link to the directory I will be pulling from on the UNIX server.

Alternatively, I can see if UNIX admins have any sort of software set up to view our network.

I have some grovelling to do, but first - thank you again for your help!

EDIT:

     Oh, and to be clear - the reason for the process is I have built a suite of fully automated tools through SAS.  We are bottle necking on our connections to the data source so I wanted to have a SAS job control and schedule all of the other jobs from an external interface where all of the schedules are picked and organized but SAS just picks up the schedule from it, all of which I have already built.  I just couldn't get this SAS job to kick off other SAS jobs on the network without uploading them up onto the server first.

John

[Tom]

Not sure how Enterprise Guide is fitting into this picture.  For %INCLUDE to work the file needs to be a text file with SAS code in it.  Not an Enterprise Guide project file.

If you had an FTP server running on one of your Windows machines then you could just change the FILENAME statement to use FTP engine to point to the file.

1. FILENAME pcfile FTP 'sasEGPFile.sas' cd='\\servername\pathname\'   .... ; 
2. %include pcfile;

[JohnSimmons]

Good morning Tom,

Thank you for the reply - I will try this and see how it works.  I certainly do have FILENAME FTP set up for other processes I'm doing to access data, if that can help me call a .SAS file, it would be a welcomed component for this task.

I'll post back here after I have some time to test it this morning.

John

[TimArm]

Hello John,

On our unix server we have Samba installed so that we can access the same disk area from unix and Windows. Do you have samba installed - or is it something you can ask your Unix Administrator to install?

This means I can edit a file on Windows as X:\sharename\file.sas, and then include it from a job running on unix as /usr/data/sharename/file.sas

Regards,

Tim

[JohnSimmons]

Good morning TimArm,

That was one of the things Quentin suggested as well, I already have an e-mail out to see if they have it installed and I have been reading documentation last night about how to utilize it to get what I want.

Thank you for the suggestion, you guys have all been very helpful in giving me ideas that I did not have before.

John