Developer Documentation Library > IBM SPSS Collaboration and Deployment Services > Connecting to a IBM SPSS Collaboration and Deployment Services Repository > UNICOM Intelligence Execution Server > Known issues
 
Known issues
Scenarios that might cause the Execution Server to become unresponsive
When using TOM to generate reports for .dms or .mrs scripts, if a report output file already exists, TOM produces a message dialog that asks whether to overwrite the existing file. Considering that the scripts are automatically processed by the Execution Server, the service will be unresponsive until all message dialogs are resolved.
Take the following sample scenario as an example:
' Export the table
With TableDoc.Exports.mrHtmlExport
  .Properties["Interactive"] = True
  .Properties["DisplayOption"] = "Table Only"
  .Export(OUTPUT_REPORT)
End With
When the output report file exists, an overwrite message dialog displays.
To avoid such cases, the script needs to either delete the existing report before execution:
If fso.FileExists("\\xiws206\share\report.htm") Then
  fso.DeleteFile("\\xiws206\share\report.htm")
End If
or set the properties to force an overwrite of the existing file:
.Properties["Interactive"] = False
.Properties["OverwriteOutput"] = True
Large UNICOM Intelligence data files
Large (greater than several GB) UNICOM Intelligence data files cannot currently be stored to a IBM SPSS Collaboration and Deployment Services Repository.
When a script retrieve its working directory, it always receives the job step’s last-set value, not the actual execution directory. The job step’s last-set value is retrieved because the current directory variable is the process-level variable, which is shared by all threads. When a job step starts to run, it sets the current directory as its execution directory. However, the job step cannot prevent the directory variable from being changed by other threads (or by the script code).
For example, the script fso.GetAbsolutePathName(".\") returns the last-set value, but it cannot ensure that the execution directory is retrieved from the current script. To work-around this limitation, the Execution Server persists the script’s working directory to a define statement at the top of the script when the script is run. User created script must use the defined variable instead of calling fso.GetAbsolutePathName(".\") when retrieving the script’s working directory:
Dim ScriptWorkingDirectory
#ifndef EXECUTIONSERVICE_WORKINGDIRECTORY
  Debug.Log("Using fso.GetAbsolutePathName("".\"") ")
  ScriptWorkingDirectory= fso.GetAbsolutePathName(".\")
#else
  Debug.Log("Using EXECUTIONSERVICE_WORKINGDIRECTORY")
  ScriptWorkingDirectory= EXECUTIONSERVICE_WORKINGDIRECTORY
#endif
The solution is referred from the mrScriptCL command line option /d:definition[=value]. For more information, see mrScript Command Line Runner.
See also
UNICOM Intelligence Execution Server