• Print |
• E-mail  |
• Bookmark

When attempting to run a request using the Stored Process Server, if the Object Spawner cannot launch the Stored Process Server, then the "sassrv" user account may not have the permissions it requires to start the server. This SAS Note provides some tips for checking the privileges of the "sassrv" account (the default "Login" account for the Stored Process Server).

1. The "sassrv" account needs permission to write to the "StoredProcessServer/logs" directory, to access the SAS configuration file, to access the SASUSER directory, to write to the SAS WORK library, and permission to execute the "sas.exe" executable that is used to start the Stored Process Server.
2. The "sassrv" account (and user accounts that submit requests) must be granted "Log on as a batch job" permission/policy on the Windows operating system. On Windows NT and Windows 2000, you must grant "Act as part of the Operating System" to "SAS General Server" group.
3. If the Object Spawner attempts to launch the Stored Process Server, but cannot, you may see the below WARNING message in your Object Spawner's log file:

         WARNING: An error occurred while server (xxxxxxxx.xxxxxxxx)
                  was starting.  Now attempting a different server.
        

   Alternatively, you may see the below error message:

         ERROR: The server failed to start.
        

4. The following approach should help test that the "sassrv" account has sufficient privileges.
   1. In your Stored Process Server directory (e.g. C:\SAS\<project name>\Lev1\SASMain\StoredProcessServer) create the following two files.
      1. Create a file called "debug_test.sas" that contains the following code:
         filename in pipe "set"; data _null_; infile in; input; list; run;
      2. Create a file called "debug_test.bat" that contains the following line. Change "C:\Program Files\SAS\SAS 9.1\sas.exe" to your site-specific path for your SAS executable. The line is (this command must be on ONE LINE):
         "C:\Program Files\SAS\SAS 9.1\sas.exe" -verbose -terminal -sysin debug_test.sas -config sasv9_StorProcSrv.cfg
   2. From a DOS shell, issue the below command:

      > runas /user:sassrv cmd

      You will be prompted to enter the password for your "sassrv" account. This will cause a new DOS window to be opened. At the top of the new DOS window you should see "cmd(running as xxxxx\sassrv)"

   3. In the newly opened DOS window (which is running under the privileges of your "sassrv" account), use the "cd" command to go to the Windows directory where you created your "debug_test.bat" file. Then, issue the below command:

      > debug_test.bat

   4. If the above test was successful, a SAS log file should be created in the "Stored Process Server" logs directory (which is under the "StoredProcessServer" directory).

      Check this log file and look for error messages. If this log file was not created, then the "sassrv" account probably does not have permission to write to the "logs" directory. Also, check your "sasv9_StorProcSrv.cfg" file to make sure the "-log" path is correct.

5. If your Stored Process Server ran successfully in the past, but will not run successfully now, then try the following.
   1. Restart your Object Spawner. Then, submit a request to your Stored Process Server.
   2. If your Stored Process Server still does not run successfully after restarting your Object Spawner, then it is possible that you may have a "hung" Stored Process Server. You can check this scenario as follows:
      1. Stop your Object Spawner
      2. Bring up a DOS shell and issue the below commands. This assumes that your Stored Process Servers are running on the default ports. If your Stored Process Servers are running on different ports, then substitute your ports in place of 8611, 8621 and 8631.

                      >  netstat -ano | find "8611"
                      >  netstat -ano | find "8621"
                      >  netstat -ano | find "8631"
                    

         If any of these ports are in use, then the above commands will provide information about the port status and "Process Id" (PID) information. If any of these ports are being used, then you probably have a "hung" Stored Process Server. You can use the Windows Task Manager to "kill" the process (identified by the PID and the "Image Name" will be "sas.exe") that that is associated with the port.

         For more information, see SAS Note #017488 .

      3. Restart your Stored Process Server.
6. Check the path for your Stored Process Server configuration file, defined in the SAS Management Console, to confirm it is correct.
7. See SAS Note #017336 for more tips.

Select the Hot Fix tab in this note to access the hot fix for this issue.

Operating System and Release Information

A fix for this issue for Add-In for Microsoft Office 2.1 is available at: