Jobs

The Job is a defined executable action, which can be either OS command or SQL script. It can perform any useful task, such as a database server backup, UPDATE STATISTICS operation or collection of OS environment information when database server performance degrades below a specified threshold level. You can easily define most of your standard existing server administration scripts as Server Studio JE jobs in order to get the following advantages:

You can create a single graphical console for all your scripts for all instances of managed database servers. With this console you do not have to switch to multiple telnet terminal sessions and memorize different physical script names and directories on different hosts under different operating systems. You have a single centralized list, under which each job has clear logical name, description, last execution time, status and history. It displays the next execution time as well, if the job is scheduled for an execution.
You can simultaneously start multiple jobs on multiple servers. For example, you can start UPDATE STATISTICS jobs for all of your servers at ones. It does not matter which operating system these servers run on.
You can see all failed jobs in the single screen instead of checking the status of multiple terminal windows or multiple log files. You can also configure the system to send you email, pager or mobile phone alert message when critical job fails.
You can schedule job executions using centralized, highly flexible scheduler utility. The scheduler works equally well for all servers, regardless of their operating systems, thus eliminating the need for different, operating system-dependent scheduling utilities.
You can execute a job as a response to any user-defined monitor event. For example, to execute a flash checkpoint command when the physical log is almost full.
Entire job execution history for all jobs with all text outputs is logged. So if you use a job to collect statistical information about your system, all data is logged automatically in the repository database, without you having to write special utility for it.

And best of all, in order to get all these advantages, a minimum effort is required to define a job. This includes entering logical job name, specifying an existing script host and location and defining failure or success text pattern string.

The Sentinel server executes a job when:

The user explicitly requests to execute it from the SSJE UI
Job is scheduled to be executed using the Job Scheduler
Job execution is triggered by a monitor alert event

The job can be defined to be executed against any host workstation that Sentinel server can communicate with via Telnet, SSH or JDBC protocol, but in majority of cases you will define jobs to be executed against the same host where your database server resides so that you could automate database maintenance tasks for that database server.

The Sentinel server executes job in the background, thus there is no need to keep SSJE UI opened when a long job is started. For example, you can start 3 hours backup job from the SSJE UI, make sure that the execution is started, and then close the SSJE application and logout from your workstation. Next morning you can start the SSJE UI and check on the status of the job as well as to see the text output produced by the job during an execution. If the job execution fails or is cancelled by user, the alert event is generated. You can view job failure alert events using the Alert Viewer. The entire jobs execution history can be reviewed in the Job History tab of the Job Properties panel.

While a job is being executed, you can see the text output produced by the job in real-time, using the Last Execution tab in the Job Properties panel. This is useful when executing long running OS commands that might produce some progress messages, such as Informix ONTAPE utility, and you want to monitor the job progress. You can also close the SSJE UI, reopen it at any time and continue monitoring the job execution progress. For an SQL job, the output is produced only ones, after the entire SQL script execution is completed.