02-10-2017 11:07 AM
Hi. I'm a SAS server admin. I've managed to set up SAS Foundation 9.4 on a remote Windows server and share it so that I can run it from another server (shortcut on my "client" server that points to local sasv9.cfg; cfg file points to shared installation on remote server). I have proc lca installed on the remote server and I can successfully run a proc lca test if I am logged in directly to the remote server. However, I can't get it to run properly from my client. Is there a way for me to point my client to the remote server for third party procs?
Sorry if this actually is more of a programming question.
02-11-2017 09:42 PM
When you say that you cannot proberly run it, what exactly does that mean?
What are the errors, warning? What are the symptoms that it is not running correctly?
What DBMS version and what SAS version are you running? Is the dbms client running on your client machine?
02-13-2017 09:52 AM
The SAS version is 9.4 TS1M2. I don't have DBMS installed on the server or client, and I don't see any option for it during installation. I did not originally have any SAS installation on the client - just the sasv9.cfg file that pointed everything to the shared installation (except for temporary work files), and the sas shortcut that pointed to that config file. That allowed me to run SAS on the client. After I got the proc lca error, I installed the client option from the depot, but that didn't have any obvious effect on how SAS or the procedure runs.
I've attached an image of the error I get when I try to run a proc lca test on the client. I am able to exit at the command prompt spawned during the test.
Here is the proc lca test code.
DATA test; INPUT it1 it2 it3 it4 count; DATALINES; 1 1 1 1 5 1 1 1 2 5 1 1 2 1 9 1 1 2 2 8 1 2 1 2 5 1 2 2 1 8 1 2 2 2 4 2 1 1 1 5 2 1 1 2 3 2 1 2 1 6 2 1 2 2 8 2 2 1 1 3 2 2 1 2 7 2 2 2 1 5 2 2 2 2 10 ; RUN; PROC LCA DATA=test; NCLASS 2; ITEMS it1 it2 it3 it4; CATEGORIES 2 2 2 2; FREQ count; SEED 100000; RHO PRIOR=1; RUN;
02-12-2017 11:54 AM
maybe you could give us some additional details of your customized configuration to call SAS (local sasv9.cfg)?
Besides the license implications of your question, where I do not want to come in: I guess that maybe you will need a local installation as well? All depends on your configuration.
Also, did you also shared your question with the creators of the procedure?
02-12-2017 12:05 PM
PROC LCA is a third-party proc, correct? I'm not sure what actions the install process takes -- it might update some search paths or environment variables. You should check the PATH= options on the remote server, and also compare the PROC OPTIONS output for both environments.
02-13-2017 08:25 AM
Hi, all. Just wanted to give a quick thanks for the responses. I'll add more details about the error and the setup in a bit.
- We have a site license for Gold Tier
- I did send a message to the proc lca developers
02-13-2017 09:30 AM
sending it to the lca developers might help to get closer to the solution. I looked around for this error and
a lot of things came up third party related.
Let us know what you'll find out.
02-13-2017 11:01 AM
The proc lca developer has never run it in a server/client configuration, so he wasn't able to help.
Next question - if we forget about the 3rd party proc, am I doing something really unusual here? Base SAS seems to be working with the main installation on a remote server and the client deployed locally, but I want to make sure what I'm doing is supported.
02-13-2017 02:24 PM
If you are running SAS jobs on both your remote SAS server and your local SAS server and you are licensed for only ONE SAS server then I think you could be breaking your SAS licence terms and conditions.
Usually your SAS licence will contain the host name of the server you are licensed for. If you run this SAS image on another server you will get a warning in the SAS log that you are not licensed for this host / server.
02-16-2017 08:21 AM
It looks like the only way I'll be able to let people run a 3rd party proc is to use local installations on all servers.
Thanks for the responses.
02-18-2017 06:41 PM
Are you mapping the remote SAS foundation install to a network drive letter before you run it or just running it from a UNC (\\server\path) path?
02-19-2017 08:16 AM
I do. Further to that, if the developer states that it's only ever run locally then there may be a couple of things you could try. You say logging on to the remote server and running Foundation from where it was installed works. So, if mapping that remote SASFoundation location to a drive letter on your client and then running it doesn't work, then this would be my approach:
1. Try logging on directly to the remote server, but accessing your SASFoundation via a UNC path to the local server as you did remotely before (\\localserverimloggedinto\SASFoundation\whatever). I'd probably expect it to fail.
2. Log on to the remote server and map that same UNC path (referring to the server itself) to another drive letter, effectively remapping SASFoundation's installed location (kind of similar to moving it). Try running it.
If step 1 works then there may be something you need in the registry (which I seriously doubt). If step 1 fails but step 2 works, then it means that your lib may depend on a hardcoded path somewhere that it looks up locally at runtime, while at the same time disliking UNC paths (as a lot of apps do).
My solution to this problem either way would be to either remap your SASHOME to an arbitrary drive letter that can be shared by all your client machines (ie. they can all remotely map it identically as G:\SASFoundation or something) and then reinstalling your PROC LCA directly to that 'remounted' arbitrary drive letter foundation location, or even better, reinstalling all of SASFoundation from scratch onto a path which you can replicate via mapping the remote location onto the same drive/letter on each of your client machines.
I'd expect this to work, but I'm almost certain that you won't need to go to all that trouble - just mapping your SASFoundation to a drive letter and launching from there should do the trick. Lots of windows apps, especially older ones, don't like UNC paths.