"Preparing server" message with EG

[BruceBrad]

I'm trying to run some SAS programs via EG (8.2 32bit). I'm using a local server on windows 10 (9.4, 64bit). The first time I run a program during a session, I get a "preparing server" status for about a minute before any calculations start.

Is this normal? (Running the program as a batch job only takes a few seconds). Can I get the server to startup in the background before I use it?

[SASKiwi]

AFAIK that is a normal message. I've seen it with remote SAS servers. The slower your network link, for example working from home over VPN, the longer the message displays. In your case it would be the overhead of starting a local SAS server. I suggest you have Windows Task Manager open when you start an EG session to see what resources are being used. That may give you some clues as to why it takes a minute to start.

[Kurt_Bremser]

I moved this to the Enterprise Guide community.

It may be that your setup for the workspace server has a lot of code to run before it becomes available for you.

Do you have code defined in EG to send to the server as soon as communication is established?

[BruceBrad]

Not really. I have an autoexec.sas file which runs a macro to define some macro variables pointing to file locations. But this loads quickly when I run SAS directly.

[ChrisHemedinger]

Turning on Application Logging (in Tools->Options) might reveal something in the details.  Those logs are not meant for a lay person to read, but if you can't determine the bottleneck I suggest working with SAS Tech Support.  Potential slowdowns can be - startup code, lots of libraries assigned at startup (including metadata libraries).

[CaseySmith]

Loading the system printers can slow down SAS server connections.  You can avoid this by using the NOPRNGETLIST option.

https://support.sas.com/kb/33/562.html

https://communities.sas.com/t5/SAS-Procedures/slow-initialization/td-p/245136#

https://communities.sas.com/t5/General-SAS-Programming/SAS-9-4-Very-slow-or-not-responding/td-p/4256...

Granted, your locally registered SAS command should already be using the NOPRNGETLIST option.  I recommend submitting the following code then checking the log to ensure the option is set to NOPRNGETLIST and not PRNGETLIST:

proc options option=NOPRNGETLIST;
run;

If it is not set to NOPRNGETLIST, I'd definitely update your locally registered SAS command or .cfg to use that option, since there is a known performance penalty without it.

If the option is already set to NOPRNGETLIST, then I'd try a local connection using the SAS Integration Technologies Configuration Wizard tool (C:\Program Files\SASHome\x86\Integration Technologies\ITConfig2.exe) (Test SAS Servers, Next, Next, change Connection Protocol to COM, click Test) and see how the time to make a connection from that tool compares with EG.  If they are not roughly the same, it points to initialization code as a likely culprit.

I found the solution for another server initialization slowdown I encountered recently in this paper:

https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2018/2003-2018.pdf

In my specific case, it was the DNS resolution was taking a long time, which I confirmed and fixed with the steps in the section, "Addressing Issues with gethostbyaddress Calls in Virtual Machine Environments".

That paper has several other possible culprits to explore, so I recommend checking it out.

Casey

[BruceBrad]

Thanks for the detailed comments:

- Proc options showed NOPRNGETLIST to be in effect

- I couldn't get the Wizard tool to work. I don't know how to enter the authentication info.

I've put in a service call to SAS support. I'll report back on what they find.

[BruceBrad · Accepted solution]

After some back and forth with SAS support, I have the solution. There was a network problem with the VirtualBox software network adapter (installed to use SAS University edition). Either disabling the network adapter or putting the following entries in my windows HOSTS file fixed the EG problem. (I haven't checked whether University edition works now - I was just testing that out).

127.0.0.1 localhost

192.168.56.1 [my computer name]

[CaseySmith]

Glad that resolved your issue!  That looks like the same issue I ran into recently and the same solution (in the paper I linked).

Casey