05-31-2016 10:13 AM
I'm playing around on a new SAS server and having a hard time understanding a bit of the architecture. Of course I'm talking with the admins, but curious if this is a common setup.
Have a linux SAS server running 9.4, accessed from E.G.
In EG, when it connects to server, it runs:
signon local sascmd="!sascmd";
From reading the SAS/Connect docs, it looks like this is starting a new SAS session on the same workspace server that is used by my EG session. ("symmetric multiprocessing"?).
Then in the pre code and post code to each code submission, they have rsubmit; and endrsubmit;
So every time an EG user submits code, it is not actually executing in the session that EG is connected to, it is being remote submitted to the second session. And all of this is transparent to the user (when it works well. : ).
I'm curious what the benefit is to this approach.
I read a little about symmetric multiprocessing. And I can see how if a user was using this to manage their own parallel processing by using multiple asycnhronous sessions, this would be useful.
But in this case everything is synchronous, and all the code a user submits is executing in the second session, without ever using the main session which EG is connected to. Is there a benefit to this approach?
In my first couple days of using it, I'm hittling little problems, for example I have code that tries to detect if it is running on EG, and get's information macro macro variables that only exist when EG is the client. That code doesn't work, because the code I submitted isn't actually running in the EG session, it's running in the side session. If I want to see what is happening in the main EG session symbol table , I need to code: endrsubmit; %put _global_; rsubmit; to break out of the rsumbit wrapper added by the precode/postcode. I will be able to overcome that sort of stuff.
Just curious if I am interpretting this correctly (i.e. that SIGNON statement really is creating a separate SAS session on the same server that EG session is running on?) and why this might be useful.
05-31-2016 11:45 AM