SAS® AppDev Studio 3.0 Developer's Site

Remote Access Troubleshooting Guide

There are a variety of problems that can prevent applications from accessing objects on the SAS server. The best way to resolve such failures is to approach them methodically, checking all of the possible causes in turn. So, when presented with a remote access failure, we suggest that you try the following troubleshooting steps in order.

Step 1

The connection customizer that is used to define the remote host connection options includes a small test program that can validate a good part of the path between the client application and the SAS server.

  1. To execute the test in

    • webAF, bring up the connection customizer for the connection in question.

    • webEIS, select Tools [arrow] Remote Connection, select the connection name in the list, click Edit.

  2. Select the Test tab on the Edit Connection dialog. Select Check Connection.

If the connection test succeeds, skip to Step 4 below. Otherwise, proceed to Step 2.

Step 2

Make sure that the remote host is accessible. The best way to do this is to use the ping command from a DOS prompt as follows:

ping <hostname>

If the ping fails, then there is a problem with the network connection from your client machine to the server. You will need to contact your network administrator to resolve this problem before proceeding.

Step 3

Make sure that the SAS spawner is configured properly on the remote host. By default, webAF and webEIS applications expect that the spawner is running on port 2323 and that it is configured to use the TCP/IP protocol. You can verify that the spawner is running on the remote host at the correct port by executing the telnet command from a DOS prompt as follows:

telnet <hostname> <port>

You should specify 2323 as the port unless you know that the webAF or webEIS application has been developed to talk to the spawner on a different port.

If the spawner is running on the remote host at the specified port, then you should get one of the following prompts depending upon whether or not you are running the spawner in secure mode:

If you receive the prompt for a non-secure spawner

Type the following command at the prompt in the telnet window:

sas -dmr

You should then see a message like the following in the telnet window:


Note that you will not be able to see what you type and mistakes cannot be corrected by hitting backspace. You might want to simply copy and paste the above command into the telnet window. When you exit telnet, the SAS session you started will be terminated. If you do not see this message, it may be the case that spawner cannot find the specified SAS executable. See Step 4 for more information on how to resolve that problem.

In some cases, if the spawner is running as a Windows service, it may also be possible that the spawner is not executing with the appropriate user rights and is not allowed to run the SAS executable. This problem occurs most often with heavily administered servers. Executing the spawner from command line will not require these user rights and is a good way to test to see if that is indeed the problem. If you have this problem, please refer to the SAS Spawner documentation for more information on executing spawner as a Windows service.

If you receive the prompt for a secure spawner

Double check that your user name and password are entered in the Prompts tab of the Edit Connection dialog used in Step 1. If you do not want to have your user name and password stored with the application or document, be sure to clear those fields and select the Prompt for user name and password at runtime option on the Connection tab.

If you do not receive the prompt for a spawner

If you do not get either of these prompts as a result of the telnet command, then the spawner needs to be started on the remote host or it is running on a different port that that specified in the connection. The port specified in the connection must match the port on which the spawner is listening. Check with the administrator of the host machine to resolve this problem before proceeding.

Step 4

If the spawner is running and is accessible from webAF or webEIS, then the next step is to ensure that the spawner is executing the correct installation of the SAS System on the remote host.

There are a couple of ways to ensure that spawner is running the correct SAS installation:

Finally, confirm that the correct SAS command string is entered in the connection customizer by attempting to execute the same command from a command prompt on the SAS server machine.

Step 5

If the correct installation of SAS is being started by the spawner, then make sure that the proper and files are being read upon startup of the SAS session. If you have multiple and files, you should use the -config and -autoexec options in the SAS Command on the Connection tab of the Edit Connection dialog to ensure that the correct copies are being used.

Also, you can run the following in SAS to verify much of installation:

af c=sashelp.rocfsmp.test.scl

The test should execute without reporting any errors. If errors are reported, then you must re-install the SAS AppDev Studio Server Side Catalogs.

Finally, you should verify that all necessary products are licensed on the SAS server system. You can list the licensed products for a SAS installation by submitting the following program from the SAS Program Editor:

proc setinit; run;

Step 6

Now that you have verified that the correct copy of SAS is being executed and any required or entries are being processed, one remaining possibility is that the object in question does not exist. Verify that the object exists. If the object does not exist, then you will need to make sure to create it or copy it as needed.

If the object does exist, then it is time to capture the SAS server log to see if a server side failure is causing the problem. See the SAS Note #23249 for details on how to trace the server-side activity.