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:

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:

or set the properties to force an overwrite of the existing file:

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:

The solution is referred from the mrScriptCL command line option /d:definition[=value]. For more information, see mrScript Command Line Runner.