Benefits of SAS/Connect symmetric multiprocessing via EG

Quentin — Tue, 31 May 2016 14:13:59 GMT

Hi All,

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.

Thanks,

--Q.

Re: Benefits of SAS/Connect symmetric multiprocessing via EG

LinusH — Tue, 31 May 2016 15:45:53 GMT

I haven't used this from EG. But your findings sounds correct.
But I think that the overhead for starting a new SAS session is quite small, just need a few MB. But the code will look unnecessary complicated. Perhaps you could turn this off by default and use it explicitly?

topic Benefits of SAS/Connect symmetric multiprocessing via EG in SAS Enterprise Guide

Benefits of SAS/Connect symmetric multiprocessing via EG

Re: Benefits of SAS/Connect symmetric multiprocessing via EG