may be a dumb question, but:

Following development and testing, we typically monitor (visually) the execution of a script in the trace window. On occasion, we see that the script is not doing what we'd like, and opt to terminate it. We do that now by issuing a control-break sequence, but this brings down the whole schedule.

Is there a better way to terminate an errant sctipt?

Rick

Closing the application console (in MS Windows terms) always closes the application that own the console and unfortunatelly there is no way to prevent it.

You may want to test your jobs from the DOS command line using the "24x7 /JOB" command so a job would run in it own instance. Terminating such job with CTRL+BREAK would not impact the main schedule.

I am not aware of any other convinient way to stop a script job being tested.

: may be a dumb question, but: Following development and testing, we typically
: monitor (visually) the execution of a script in the trace window. On
: occasion, we see that the script is not doing what we'd like, and opt to
: terminate it. We do that now by issuing a control-break sequence, but this
: brings down the whole schedule.

: Is there a better way to terminate an errant sctipt?

: Rick

: Closing the application console (in MS Windows terms) always closes the
: application that own the console and unfortunatelly there is no way to
: prevent it.

: You may want to test your jobs from the DOS command line using the "24x7
: /JOB" command so a job would run in it own instance. Terminating such
: job with CTRL+BREAK would not impact the main schedule.

: I am not aware of any other convinient way to stop a script job being tested.

Testing from DOS is okay - better than crashing the whole schedule...