SAS Connect and "Conversation termination; status=1." error

[rwan1]

Dear all,

I am an administrator of an SAS installation on Ubuntu (SAS 9.4_M6) running SAS Connect to allow a remote user to connect to it.  I've been informed by a user that the setup works fine for small tasks, but for larger ones, there is a time out with an error:

"Conversation termination; status=1"

There are two relevant knowledge base articles:  http://support.sas.com/kb/62/319.html and http://support.sas.com/kb/33/650.html .

In the first one, I'm asked to install a hotfix:   D9T001.  I did that.  It also asks me to put this:

-set CONNECTKEEPALIVE <n seconds> 

in the connect server's launch command.  I don't know if I've misunderstood this, but I basically changed the spawner so that it starts up (via a service) like this:

./cntspawn -mgmtport 7555 -sascmd /opt/sas/sas-cmd.sh -service 7551 -set CONNECTKEEPALIVE 5

This hasn't solved the user's problem.  The second article refers to the z/OS operating system.  Nevertheless, I thought I can still try to follow it since that is Unix and so is Ubuntu.  However, I don't quite understand what it is asking me to do:

Increasing the CPUTIMEMAX value might help you to avoid this problem. You can change the parameter for an individual user ID in the Open MVS segment that defines the user ID. You can change the parameter for all user IDs in the BPXPRM00 member in SYS1.PARMLIB.

Unfortunately, I'm somewhat new to administering an SAS instance and I can't quite understand what that paragraph is asking me to do.

Finally, I did search these forums using the search phrase "Conversation termination; status=1".  Indeed, there are postings and replies so others have experienced this before.  But some of the replies suggest that the original poster ask the system administrator to make that change...  Unfortunately, I am the system administrator and I have no one (other than these forums) to turn to...  Can someone offer some suggestions as to what I should do or what I have been doing wrong?

Thank you in advance!

Ray

[SASKiwi]

I suggest you talk to your IT network folks and ask them to monitor the network traffic of your SAS App server and in particular the SAS/CONNECT spawner port. If timeouts are still happening then the traffic log should be showing these. They should also now if there are any relevant firewall rules. In my experience it is better to configure firewall rules than to use "keepalive" functionality.

[doug_sas]

Conversation termination is hard to debug. We usually require the customer to get logs from the client, spawner, and server with additional tracing.

Just set the App.Connect logger to trace on all three and gather the logs after the termination.

[Resa]

We have been and occasionaly are facing a similar issue and I agree with @doug_sas that these issues are hard to debug.

We have had - and sorry, can't explain why - a reduction in occurrence by adding a "sleep" between the queries that we were sending to the remote host, like below:

<code part 1>

data _null_;
   call sleep (2,1);
run;

<code part 2>

data _null_;
   call sleep (2,1);
run;

<code part n>

Furthermore we have been monitoring the remote connections with the Linux lsof command on the connect spawner port and indeed noticed that occassionally the connection gets lost. Up until now without finding out the reason why.

Finally, in the remote sessions we are querying a database and we noticed that occassionally our remote session became unresponsive because the database was unresponsive.

All in all quite a lot of possible causes and baby steps to prevent it from occurring.

Good luck and hope you can fully prevent it from happening

[rwan1]

Dear all,

Thank you for your prompt replies!  Honestly, I thought it was a simple matter of me overlooking something very simple in either configuration of the server or SAS.  I will look into the network logs and also inform the user about the time out and get back to this thread if I've found something.

I didn't think it was important, but I neglected to mention that the distance between the server and client is very far.  I'm talking about on the order of North America to Asia.  For this type of distance, I wouldn't even suggest a client to have X11 windows pop up -- it would be incredibly slow and even an editor like vim or emacs would be painful, let alone a more graphic intensive application.  Could this distance contribute to some kind of latency and result in this problem happening more often than a situation where the client and server are both within the same building?

The server in question actually has a job scheduler installed (i.e., SLURM).  And I wonder if this problem persists, would shifting the work over to the server might be a more feasible solution.

In any case, I will try some of what you've suggested before I try to reply to each of your suggestions -- thanks a lot for the help!

Ray